On Apr 6, 2009, at 9:02 PM, Michael Ash wrote:
On Mon, Apr 6, 2009 at 11:10 PM, Adam R. Maxwell <[email protected]> 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 thatreadToEndOfFileInBackgroundAndNotify 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 thenotifications (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: "NSFileHandleReadToEndOfFileCompletionNotificationThis 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).
It could very well be implemented by installing the socket directly on the runloop, for example by using CFFileDEscriptor, and performing all reads on the thread you call it from. It obviously isn't implemented that way *now*, but it could be done that way in the future. It would still be a very useful method, but it wouldn't work the way you're using it.
The documentation says that it "performs an asynchronous readToEndOfFile" (which I'd guess is actually -readDataToEndOfFile); since that call blocks the calling thread, Apple would have to rewrite the documentation to tell us that it's using a runloop source instead, since there are different caveats that come with that.
I'd justditch your waitUntilExit altogether. All you should really care aboutis an end to the data coming in.I'd ditch the sleep and keep the -waitUntilExit, since NSTask throws anexception if you call -terminationStatus before the task has actuallyexited. And I'd put most of this code in an exception handler, since NSTaskhas a really unpleasant habit of throwing exceptions unexpectedly.Well obviously if you're going to dump the waitUntilExt, you'd dump the terminationStatus too. Either forget about it altogether, because it's probably not important here, or register for NSTaskDidTerminateNotification and query the terminationStatus in the callback.
Obvious to you, but to someone who's getting started with NSTask (as the OP is), it may not be obvious; ignoring -terminationStatus is a bad habit, in my opinion. Anyway, sometimes using a synchronous method is more straightforward than using the notifications, and I had various reasons for doing so at the time.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Cocoa-dev mailing list ([email protected]) 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 [email protected]
