• 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: NSPipe eating up all available pipes on system.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSPipe eating up all available pipes on system.


  • Subject: Re: NSPipe eating up all available pipes on system.
  • From: Ken Thomases <email@hidden>
  • Date: Fri, 22 Feb 2013 18:46:06 -0600

On Feb 22, 2013, at 5:52 PM, Mr. Gecko wrote:

> On Feb 22, 2013, at 10:47 AM, Willeke <email@hidden> 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 (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

References: 
 >NSPipe eating up all available pipes on system. (From: "Mr. Gecko" <email@hidden>)
 >Re: NSPipe eating up all available pipes on system. (From: Ken Thomases <email@hidden>)
 >Re: NSPipe eating up all available pipes on system. (From: "Mr. Gecko" <email@hidden>)
 >Re: NSPipe eating up all available pipes on system. (From: Willeke <email@hidden>)
 >Re: NSPipe eating up all available pipes on system. (From: "Mr. Gecko" <email@hidden>)

  • Prev by Date: Re: NSPipe eating up all available pipes on system.
  • Next by Date: Problem with NSDatePicker in popover
  • Previous by thread: Re: NSPipe eating up all available pipes on system.
  • Next by thread: Re: NSPipe eating up all available pipes on system.
  • Index(es):
    • Date
    • Thread