Re: File descriptors not freed up without a -closeFile call
Re: File descriptors not freed up without a -closeFile call
- Subject: Re: File descriptors not freed up without a -closeFile call
- From: Ben Haller <email@hidden>
- Date: Wed, 23 Jun 2010 07:42:59 -0400
On 23-Jun-10, at 6:59 AM, email@hidden wrote:
On 23 Jun 2010, at 11:47, Ben Haller wrote:
On 23-Jun-10, at 6:22 AM, Uli Kusterer wrote:
Am Jun 23, 2010 um 12:14 PM schrieb Ben Haller:
So I have a workaround for the problem, but I want to understand
*why* it works. Shouldn't NSPipe close its associated files when
it deallocs? Why should it be necessary to call -closeFile?
This behavior seems to be specifically contradicted by the
documentation on NSPipe, which says (in -fileHandleForReading)
"The descriptor represented by this object is deleted, and the
object itself is automatically deallocated when the receiver is
deallocated." Well, when my NSPipes are deallocated, the file
handles are indeed automatically deallocated (a funny way to put
it), but the descriptor is *not* deleted. Is this a bug? More
likely I'm misunderstanding something; can anybody clarify this
for me?
AFAIR, NSPipe autoreleases its NSFileHandles), which means even if
you give up all your references to the pipe, it won't
automatically close everything until the current autorelease pool
gets popped. While closeFile doesn't get rid of the objects, it
forces the file handle to be closed, which is why it solves your
immediate problem.
If you're running your own loop where you create and tear down
lots of pipes, it might help to just create your own autorelease
pool inside the loop on each iteration.
Yes; this is not an autorelease pool problem, however, as I
described in my original post. The run loop is running freely, and
the pipes and file handles are in fact getting dealloced; I have
confirmed this explicitly in Instruments. And yet, the file
descriptors don't get deleted unless I explicitly call -closeFile.
That's the mystery (or is it a bug?).
To me it seems pretty explicit in the NSPipe docs
http://developer.apple.com/mac/library/documentation/cocoa/reference/foundation/Classes/NSPipe_Class/Reference/Reference.html#/
/apple_ref/occ/instm/NSPipe/fileHandleForWriting
fileHandleForReading
You use the returned file handle to read from the pipe using
NSFileHandle's read methods—availableData,readDataToEndOfFile, and
readDataOfLength:.
You don’t need to send closeFile to this object or explicitly
release the object after you have finished using it.
fileHandleForWriting
You use the returned file handle to write to the pipe using
NSFileHandle's writeData: method. When you are finished writing data
to this object, send it a closeFile message to delete the
descriptor. Deleting the descriptor causes the reading process to
receive an end-of-data signal (an empty NSData object).
So you can dispense with closeFile on the read handle.
Ah, interesting. I missed that in the docs. It still seems bad to
me that the file handle will actually dealloc without closing its
associated file descriptor, but perhaps you are right that that is the
documented behavior. I'll just stop worrying about it and move on,
then. Thanks!
Ben Haller
McGill University
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden