Re: NSCondition
Sandor Szatmari
Dave, On Mon, Mar 12, 2018 at 1:28 PM, Dave <dave@...> wrote: Hi Again Sandor, See below for what I'm talking about with the -wait call... Additionally, think about where your testing -isCancelled and breaking out of the loop(s); you have multiple loops. Does that break, break you out of all loops or just the innermost loop. Do you want to break out of all loops... if your terminating the thread, probably. Where you've placed it, It looks like you can remove an object from the queue and the break the loop without processing it... if the application were not terminating and you were going to resume processing, you would loose that one item... You also might want to check it at the head of your loop... and/or check it before you call -wait inside my suggested loop... In general where and how often you check -isCanceled can determine how responsive and well behaved an app/thread is to terminating... Just be sure to make sure your leaving everything in an expected/sane state; tearing things down properly... releasing objects... unlocking your conditions... etc.
// -------------------------------------------------------------------------------------------- // New Loop // // If the NSCondition ever gets signaled, wait again if the queue is empty. // The documentation for NSCondition explains that the condition when signaled will try to acquire the lock and the proceed // so once we acquire the lock here the next thing we will do is check the queue. // If is it not empty, we end the loop and proceed to process. // If it is empty we call wait again... (This is testing the predicate that has been referred to.) // The documentation states that calling wait will unlock the condition and and then wait to be signaled... // while ( [self. [self. //**
|
|