On Tue, Apr 7, 2009 at 12:53 AM, Adam R. Maxwell <amaxw...@mac.com> wrote: > > On Apr 6, 2009, at 9:02 PM, Michael Ash wrote: > >> On Mon, Apr 6, 2009 at 11:10 PM, Adam R. Maxwell <amaxw...@mac.com> wrote: >>> >>> On Apr 6, 2009, at 7:50 PM, Michael Ash wrote: >>>> >>>> First off, I wouldn't write code like this. You have no guarantee that >>>> readToEndOfFileInBackgroundAndNotify will actually read everything >>>> while your code is stuck in waitUntilExit, so you have the same >>>> potential for deadlock as before. It's quite possible that it >>>> immediately starts reading on a background thread and so you're >>>> perfectly safe, but it's bad to rely on that sort of thing. >>> >>> Wouldn't it be pretty useless if it didn't do that, though? If this is >>> really a problem, I'd like to know, since I use something similar. The >>> main >>> difference is that I call -readToEndOfFileInBackgroundAndNotifyForModes: >>> with a private runloop mode, then call -waitUntilExit. When >>> -waitUntilExit >>> returns, I run the runloop in that mode for a short time to pick up the >>> notifications (IIRC it takes one pass per pipe). >> >> Why would it be useless? The idea is to perform the read in the >> background, without blocking your thread, but it explicitly requires >> you to run the runloop in order to get the notification, and could >> very well implicitly require you to run the runloop in order to do any >> work at all. It would still be extremely *useful*, as it would still >> function as a fire-and-forget "go read this and tell me when you're >> done" method. It just wouldn't work for this "go read this right now >> in another thread without me even going back to the runloop" scenario >> you two are using it for. I contend based on the documentation that >> this use is simply not supported. It says "in the background" but says >> nothing about another thread. > > Actually, it does, although not directly in the method description: > > "NSFileHandleReadToEndOfFileCompletionNotification > This notification is posted when the background thread reads all data in the > file..." > > As far as I'm concerned, this is a guarantee that it's using a thread, > particularly since the method description talks about posting a notification > on the client's runloop (which I take to mean the calling thread).
True enough. On the other hand there's no guarantee of when that background thread starts its work. It could very well start that background thread during the next runloop cycle and still be within the bounds of the API contract. The background thread could even ping back to the main thread from time to time. Anyway, it's all moot for this case given that waitUntilExit is documented to run the runloop, which I didn't notice before. Given that, it's fine here. Mike _______________________________________________ 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
