On Jul 26, 2011, at 12:18 AM, Shane Stanley wrote: >> On Jul 25, 2011, at 3:40 AM, Shane Stanley wrote: >> >>>> I wonder if they've changed how the readInBackgroundAndNotify works. >>> >>> Yes, they have. I logged a bug on it, and was told that the way it worked in >>> 10.6 was wrong -- whereas it used not to send a notification until there was >>> something to read, it now returns one immediately regardless. Whether that's >>> the problem here, I don't know. >> >> That's absolutely demented. If it sends a notification immediately, with or >> without data, then you're never really using it to read in the background, >> you're almost just spinning in a busy loop, getting a probably empty NSData, >> and calling readInBackgroundAndNotify again, as fast as the runloop can >> deliver the notifications. > > Exactly. I built a sample app that did exactly that, and logged radar > #9120065. I was told that was correct behavior, and that "Snow Leopard's > NSFileHandle never correctly notified with a zero length data at EOF". The > suggested fix was "do a blocking -readDataOfLength: call on a background > thread".
- Snow Leopard most certainly did correctly notify with a zero length data at EOF for me and did so sufficiently consistently that I am not aware of it ever failing to do so, in thousands of runs. Therefore "never" is clearly incorrect. - I don't see how what you said "...it now returns one immediately regardless...." follows from Apple's response that you quoted; maybe I'm missing some context. - What good will a blocking readDataOfLength: call on a background thread do for the case where you don't know what's coming, need to process it as it comes, then need to know when it's closed? Are they seriously suggesting that we need to read a single character at a time using blocking reads on a background thread? That's such a lame suggestion that it would make me ask: why bother with NSTask and NSFileHandle and notifications at all? In that case POSIX APIs would be no harder to use, and would actually work. - I set up some tests in Lion and ran them last night, and never had an instance of getting a notification with zero-length data before the pipe was closed. Only a few dozen runs, but still, 0-length data always indicated pipe close. (I modified the command-line process with a couple of obnoxious pauses, before sending anything and before sending the final lines, so that if there's some timeout it would be likely to be hit.) Maybe you should try to re-open your bug ;-) -- 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
