Possibly- I noticed a problem with some of my code on 10.6 that sounds suspiciously like your problem.
I needed to get some network info (mostly concerning BGP and AS stuff) in a totally asynchronous manner. The ideal solution for me is to send special DNS TXT record requests to a publicly accessible DNS server, but Cocoa/Core Foundation doesn't provide an API for doing these kinds of odd ball DNS requests. Another way was to use shell% whois -h IP 'SPECIAL REQUEST'
and just parse out the relevant info from the output. This was something that I could get up and running in a matter of hours and come back later and put in a real solution. Very hacky, but an awful lot faster than 1) finding a suitable asynchronous DNS library and 2) getting up to speed on its API and possibly writing a wrapper for it.
So, I created a class that forks off a background thread, and then NSTask
to kick off the whois
request. The background thread sits in a NSRunLoop
loop to process the results, but checks every ~1/10 of a second to see if the NSTask
died for some reason, or if [NSThread isCanceled]
, etc etc. It also registers for NSApplicationWillTerminateNotification
notifications so it can do proper cleanup if the app is quitting.
Well, as of 10.6... I could no longer quit 'quickly'. On 10.5, everything is glass smooth, and the app quits instantly, at least perceptually. Under 10.6, quitting causes the app to 'hang'. Debugging showed that everything was getting hung up trying to clean up lingering whois NSTask
s. Since none of the information I get this way is critical to the apps functionality (it's extra, nice to know kind of info), I just sort of punted and stopped trying to get the info as a stop gap solution.
The quick passes at debugging the problem showed that the main app was blocking on trying to acquire the instances NSLock
. What's interesting is that if I just leave it alone, the application does eventually exit normally- anywhere from 10-20 seconds to minutes.. something changed between 10.5 and 10.6 that is causing code bracketed inside a [NSLock lock] ... [NSLock unlock]
block to 'take a long time'. I have yet to track down where that's happening, though (not yet a priority).... but one of those things is terminating the background NSTask
if it's still running and 'waiting for it to finish up' before it can safely get rid of stuff like its NSPipe
.
DUP: This might be a dupe answer... my first one seems to have vanished in to the either?