On Jul 24, 2011, at 11:01 PM, Stephen J. Butler wrote: > That is, abandon processPipeClose and let each pipe handle its own > close in the notification when you're sure all of its read > notifications have actually been delivered. As you've presented it, > processPipeClose isn't needed.
Your theory makes sense to me, and I think for now I'll assume it's the explanation for the behavior. In the real code there's things I need to do after receipt of complete output from both pipes; I just stripped that out of processPipeClose to make this easier to read. However, I can still incorporate your suggestion, and just do the "after everything" processing when the second of curStdOut & curStdErr go to nil. If I weren't feeling lazy this morning, I would dig back through version control. I think the code some time ago was more similar to your suggestion, but loaded up with some unnecessary complications, and this race condition is a result of a simplification attempt which I did not get quite right. Thanks a lot. This was, IMO, not a trivial question ;-) -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice _______________________________________________ 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
