Re: 2 NSFileHandle bugs?
Re: 2 NSFileHandle bugs?
- Subject: Re: 2 NSFileHandle bugs?
- From: Gregory Best <email@hidden>
- Date: Mon, 28 Feb 2005 16:26:46 -0800
It's unfortunate that NSFileHandle can't be subclassed directly, but I'll leave that be for now.
I am using initWithFileDescriptor:closeOnDealloc:, that didn't seem to help. I also tried closing the file descriptor with a system call.
In other news, I figured out what I was doing wrong-- I was about to send another email with a code sample showing my init and dealloc code and realized I should double check that I understood VMIN and VTIME in the struct termios c_cc[] array-- turns out that I didn't. I assumed I'd enabled a timeout when I set VTIME=10, but I'd also set VMIN=1 so what I'd turned on was an inter-byte timer that wouldn't start counting until the first byte was received. No bytes ->no timer -> blocked forever.
Hate it when people start yelling about bugs in the frameworks before they inspect their code...
Thanks for the help.
On Monday, February 28, 2005, at 05:25AM, Clark Cox <email@hidden> wrote:
>On Mon, 28 Feb 2005 05:03:18 -0800, Greg Best <email@hidden> wrote:
>> Hello--
>>
>> I've run into two NSFileHandle bugs that I want to confirm before
>> filing a report with Apple. I've searched around the web for
>> references, and it looks like others have seen these, but the threads
>> are all left unresolved...
>>
>> I'm trying to create a SerialPort class to communicate with an embedded
>> device, but I'm testing with two serial ports and a null modem cable
>> between them. The serial ports I'm using are Keyspan USB to RS-232
>> adapters.
>>
>> The first is that subclasses of NSFileHandle can't use the
>> initWithFileDescriptor: method. I've seen reference to this being
>> because NSFileHandle is really a class cluster-- and I assume this
>> method isn't wired up properly. I've worked around this by building a
>> GCBSerialPort class that contains a basic NSFileHandle and then mirrors
>> the methods to the outside so I can subclass it easily when this is
>> fixed.
>
>This is not a bug to be "fixed". This is how class clusters
>operate.Usually, if you want to subclass a class cluster, you do so by
>aggregating (as you discovered).
>
>> The second is that the NSFileHandle doesn't seem to close the device
>> properly. I've seen comments online that this is because
>> readInBackgroundAndNotify forks a thread to do the reading and doesn't
>> terminate properly and release the fd when the NSFH is released. I
>> think I've just proven that to myself by releasing my GCBSerialPort
>> (and locking up the device) and then sending data through the cable.
>> That seems to cause readInBackgroundAndNotify to return with the data
>> and die-- releasing the device.
>
>Assuming that you initialized the NSFileHandle with
>-initWithFileDescriptor:, then it is not its responsibility to close
>the file. From the documentation:
>
>-------------------------------
>- (id)initWithFileDescriptor:(int)fileDescriptor
>Returns an NSFileHandle initialized with the file descriptor
>fileDescriptor. You can create an NSFileHandle for a socket by using
>the result of a socket call as fileDescriptor. The object creating an
>NSFileHandle using this method owns fileDescriptor and is responsible
>for its disposition.
>-------------------------------
>
>Have you instead tried using the method
>-initWithFileDescriptor:closeOnDealloc: ?
>
>
>--
>Clark S. Cox III
>email@hidden
>http://www.livejournal.com/users/clarkcox3/
>http://homepage.mac.com/clarkcox3/
>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden