McLaughlin, Michael P wrote:
Is there a recommended (better) way of sending and receiving a
known (large)
amount of data to and from a subtask? Is there any sample code
anywhere
similar to what I need? I couldn't find anything close enough to
work.
Reading your description, my first thought was sockets. And more
specifically, CocoaAsyncSocket:
http://code.google.com/p/cocoaasyncsocket/
However, you still haven't completely described how your subtasks
consume input and produce output, and how the parent collects output
or other results. So sockets may not work any better.
I am assuming that subtask output or results are written to the
subtask's stdout stream, which is a pipe back to the parent process.
If all the subtasks read *all* the input data before producing any
output data, then I don't know why the parent would be blocking in
pipe-writing. The only reasons that come to mind are bugs:
misinterpretation of protocol bytes, reading the wrong sizes, etc.
If the subtasks read *some* input, then produce *any* output on
stdout, then that is an opportunity for deadlock, as I previously
described. Here's how deadlock happens: after reading some but not
all input, the subtask writes to its stdout. This is a pipe back to
its parent. The parent is NOT reading its end of the pipe. When the
pipe fills up (16 KB), the subtask is then blocked in its writing to
stdout. Since it's blocked, it no longer reads its stdin (another
pipe to parent). So if parent continues to write bytes to its end of
the pipe, and does not read from the subtask's output pipe, then the
parent will eventually block when writing to the pipe that is the
subtask's stdin. The parent is now waiting for the child to read its
input, freeing up space in the pipe, and the child is waiting for the
parent to read its input, and neither one can proceed until the other
does. Classic deadlock.
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.
Note that sockets WILL NOT prevent deadlock in this situation. If
the requester (the parent) sends enough data to the responder (the
subtask), but does not read pending responses, then TCP/IP will
eventually block, just as surely as pipes do. The size may be larger
than with pipes, but it can still happen. Neither pipes nor sockets
are infinitely buffered streams. If you treat them as such in your
software design, then that is a grave error.
I can't tell if this is the cause of the blocking or not, because you
haven't described how the subtasks produce output. You also haven't
described how the parent reads the output from the subtasks.
If the reading is fully asynchronous and infinitely buffered, then it
shouldn't deadlock. However, if it's synchronous or has a finite
buffer length, then it will deadlock under some conditions. The
exact conditions depend on the length of the buffers and the amounts
of data produced for a given input. Each pipe will hold 16 KB before
it blocks on write. Two pipes, so that account for 32 KB. The other
32 KB could be in-memory buffering in any of the processes.
If nothing else works, then I think you need to make a well-isolated
test case that exhibits the problem. The subtask can be something
simple, like the 'wc' (word-count) command-line tool. It reads all
input before producing any output, so it should never exhibit
deadlock even if your parent doesn't read any responses until all
data is sent.
-- GG
_______________________________________________
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
