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.

---

… not to rain on your parade, but the I/O has been rewritten greatly since 10.3 (IIRC) with the introduction of the NSStream classes, which are usually The Way To Go. (Of course NSFileHandle still works well, but it's not The Latest And Coolest.)

Also, reading after closing? Huh?