• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: 2 NSFileHandle bugs?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 2 NSFileHandle bugs?


  • Subject: Re: 2 NSFileHandle bugs?
  • From: Clark Cox <email@hidden>
  • Date: Mon, 28 Feb 2005 08:25:26 -0500

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

  • Follow-Ups:
    • Re: 2 NSFileHandle bugs?
      • From: Gregory Best <email@hidden>
References: 
 >2 NSFileHandle bugs? (From: Greg Best <email@hidden>)

  • Prev by Date: 2 NSFileHandle bugs?
  • Next by Date: How do I make a panel come out of the title bar
  • Previous by thread: 2 NSFileHandle bugs?
  • Next by thread: Re: 2 NSFileHandle bugs?
  • Index(es):
    • Date
    • Thread