Re: NSPipe (NSFileHandle) writedata limit?
Re: NSPipe (NSFileHandle) writedata limit?
- Subject: Re: NSPipe (NSFileHandle) writedata limit?
- From: Andrew Farmer <email@hidden>
- Date: Mon, 12 Apr 2010 21:27:47 -0700
On 12 Apr 2010, at 10:56, McLaughlin, Michael P. wrote:
> Greg Guerin wrote
>> The fundamental design is "send all data before looking for any
>> results". This is inherently synchronous, even though two or more
>> processes are involved. If the subtask is designed to "read all data
>> before producting any results", then it shouldn't deadlock. However,
>> if the subtask is designed to "read some data, produce some results",
>> then it is prone to deadlock.
>
> In my app so far, I have not even gotten to the point where the subtask
> produces any output. I am sending all data from main but main blocks iff
> the number of bytes sent > 65536.
What I think you're missing here is that pipes have a finite capacity -- this is 64K in current releases of OS X, as you've discovered, but POSIX guarantees only that it will be at least 512 bytes. As such, writing data to a pipe and then beginning to read bytes from the other end WILL cause deadlocks; you will need to start reading data from the pipe at the same time as data is being written to it. In practical terms, this means either ordering the reading end to start reading before beginning to write data to the other end, or adding the pipe fd as a runloop source._______________________________________________
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