On Feb 22, 2013, at 5:52 PM, Mr. Gecko wrote: > On Feb 22, 2013, at 10:47 AM, Willeke <willeke2...@gmail.com> wrote: > >> I don't know why but it doesn't leak if you do readInBackgroundAndNotify >> only if [data length]!=0. > > Doesn't make sense as when you release the NSPipe, it should disable that. I > will report this to apple via Rdar.
Actually, I doubt it will be considered a valid bug. When you release the pipe, all that means is that you are no longer guaranteed that it will remain around. You are not guaranteed that it will be deallocated. The framework is entitled to keep it around for its own purposes when you do something like -readInBackgroundAndNotify. Willeke is correct that you should not initiate another read after EOF (good catch!) and you _might_ report a bug about that read operation not immediately resulting in another notification with an empty data object. The reason it doesn't, though, is probably related to the part of the kqueue() documentation that says that you can clear an EOF flag and resume waiting for the pipe to be readable. https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man2/kqueue.2.html "When the last writer disconnects, the filter will set EV_EOF in flags. This may be cleared by passing in EV_CLEAR, at which point the filter will resume waiting for data to become available before returning." (It's clear to me how a FIFO could acquire a new writer after all previous writers have disconnected. It's not clear to me whether or how a pipe could, so I don't know why this semantic applies to pipes.) In this case, avoiding issuing the new background read is easy and reliable. In other cases, if you want to make sure the framework has terminated all background uses of a file handle, you can try invoking -[NSFileHandle closeFile]. However, even that is not clearly documented to terminate in-flight background operations. Regards, Ken _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
