On Jul 13, 2012, at 18:37 , Tilghman Lesher wrote:

On Fri, Jul 13, 2012 at 8:32 PM, Rick Mann <rmann@latencyzero.com> wrote:

...

Nope. Straight-up Cocoa app. I did some checking to make sure NSFileHandle was indeed closing the file descriptor, and it is. I tried closing it for it with close(), but it made no difference.

If you have lsof on your system, it's worth a try to see what else has it open. You might be surprised.

Fascinating. I open the device twice. Once when I expressly open it using POSIX, and again later, as a result of calling -readInBackgroundAndNotify on the NSFileHandle. I'm having trouble understanding the docs. They say: "If you want to use a file handle object with a file descriptor that you created, use the initWithFileDescriptor: method…" Which is what I use. But calling close on that closes the first FD, the one I opened, and leaves the second one open. If the notification gets posted, the FD is closed. It's re-opened each time -readInBackgroundAndNotify is called, and left open on closeFile. I suspect it gets closed in NSFileHandle's -dealloc, but since I'm running in ARC, and I'm not nilling out my reference to the NSFileHandle, it never gets disposed. I then go to try to open the file again, and it fails. It's not until after that that I create a new NSFileHandle and thus free the old one. One last thing I don't understand: I set the FD to TIOCEXCL, which my comment says will disallow multiple opens, and which my own code experiences (it comes back as busy), but which -readInBackgroundAndNotify doesn't seem to have a problem with. Thanks, Tilghman, for the lsof suggestion. -- Rick _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app... This email sent to site_archiver@lists.apple.com