Close calls take forever using Cocoa's asynchronous IO?

I am writing a single threaded Cocoa app and am attempting to use the NSNotificationCenter utility methodology (as that seems to be how things are done in cocoa) to do non-blocking IO.

Everything seems to work fine except for when the file handle is closed. It eventually notifies me, but it takes forever. Can anyone explain why this would be?

More specifically, I'm writing a screen saver that forks a process and reads its stdout. The behavior changes based on the context, too. When it's running in the preview window in System Preferences it notifies on close quicker then when it runs full screen when clicking the test button.

Edit: After a little thought, I believe the problem is that the last write and the close happen at about the same time. The last read occurs after the NSFileHandle has been closed, and it returns data (ie not at EOF). I finish up by waiting on it, but since the file handle is inactive the main loop will stay blocked since there's nothing to signal it to execute. The reason the preview mode works is because whenever I click on something in the System Preferences window I force the main loop to execute and it checks the status of the NSFileHandle that's being waiting on and sees that it's closed.

Now I think I know what's happening, but I still don't know how to figure out that the NSFileHandle is closed without blocking!

After some more testing this issue seems to be exclusive to when the Screen Saver is executing.

Read after close will (assuming I've already read all the buffered data) return 0 bytes, meaning EOF. I'm using `NSTask` to fork the process which produces three `NSFileHandle`'s. I don't think `NSSTream` is what I want since it seems to be exclusively for network sockets.

jdizzle 2010-01-18 14:20:02

How do you mean "happen at about the same time" ? Do you mean from different threads? Also what makes you think "Read after close will return 0 bytes" ? The docs clearly state that it will raise an exception.

2010-01-25 14:37:01

The last write and the close both come from a child process. Reading after close returns 0 bytes at least once. That's how you know you're at the EOF. If you're referring to the NSFileHandle documentation, it says it throws an exception if there's an error reading from the file handle. EOF is not an error.

jdizzle 2010-02-09 13:31:08

ansaurus

tags:

views:

answers:

Close calls take forever using Cocoa's asynchronous IO?

related questions