On 6 Oct 2009, at 13:24, Jerry Krinock wrote: Finally, is adding a little isDone condition in that while() loop the correct way to fix this?
That's not the best way to solve this, pulsing the run loop won't let the thread go to sleep and will burn CPU depending on how granular your interval. It's better to run the loop unconditionally, then stop it explicitly when you want to exit the loop, I use CFRunLoop for this as it has a stop function.
Well, the while(!isDone && [runLoop runMode:yadda beforeDate:distantFuture]) thing is a pretty standard practice, one that comes out of Apple Threading Programming Guide. I'll let you bring that discussion back on-list if you want to.
The examples given (if I recall correctly) check the exit status of the run loop method, and set the done variable based on that. But that still means that the thread needs to wake up every ten seconds and perform something.
If you already have an explicit exit condition I think it's better to explicitly stop the run loop there and then continue executing where you left off in the method which started it - this is assuming of course that the method which started the run loop is executing concurrently with respect to the main thread.
Whenever I write one of those while(run) loops I put an NSLog in there. In this case, it seems to only run/log each time there is a packet received, and that seems reasonable. If you think that there is some other CPU action going on, it would be good to reply back to the list and explain. This is another I felt was addressed by explicitly stopping the loop when finished. From the documentation re -runMode:beforeDate:
"it returns after either the first input source is processed or limitDate is reached"
Granted though I was using CFRunLoop I'd think the same principles apply. I experienced either thrashing or a delay. With too small a timeout the thread was checking the done state too aggressively, or (if you specify that you don't want the method to exit until the timeout) with to large a timeout your packet/asynchronous work has already been completed, but the user has to wait the entire timeout duration until you notice that the work is complete. So long as you aren't experiencing these issues keep doing what you're doing.
I preferred the cleaner runloop callsite which just performed CFRunLoopRun() and once it had returned the work was either done or an error had occurred.
Keith |