site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Thread-index: AcZwk74Xolo3ir3gSZye46HpuYclIACCtz5Q Thread-topic: question for CFRunLoopStop() Thanks very much for your help and analysis. The times which CFRunLoopTimerInvalidate() worked for me without calling CFRunLoopStop/CFRunLoopWakeUp could be explained (as you say) by there having been a timer callback which was currently executing, and so the timer, being invalid, could never cause another timer callback. I'll remember your tip for CFRunLoopWakeUp(), which might be helpful to me in another context. thanks, Philip Lukidis -----Original Message----- From: Kevin Van Vechten [mailto:kevin@opendarwin.org] Sent: Friday, May 05, 2006 6:30 PM To: Philip Lukidis Cc: darwin-dev@lists.apple.com Subject: Re: question for CFRunLoopStop() On May 5, 2006, at 12:20 PM, Philip Lukidis wrote:

Perhaps I am missing something, but removing/invalidating the timer from the child runloop does not always provoke the child thread to exit. So after having read your reply, I suppose that the best way to solve my problem would be to stop the runloop. But the documentation says that removing all sources from a runloop causes CFRunLoopRun() to return:

"The current thread's run loop runs in the default mode (see "Default Run Loop Mode") until the run loop is stopped with CFRunLoopStop or all the sources and timers are removed from the default run loop mode."

Looking at the CF sources, it appears that CFRunLoopTimerInvalidate() calls CFRunLoopRemoveTimer() to remove the timer from its runloop in all modes that it's registered in.

However, I do not consistently find that this is true in my case. Perhaps there is a fault in my code, but invalidating the timer does not always cause the child thread to exit (and according to the docs, invalidating a timer removes it from the runloop). However, so far CFRunLoopStop() consistently works. Offhand could you explain this?

While the runloop is waiting for events, it is blocked on a mach port read. The only way to unblock it is for a timer to fire, a source to be signaled, or to call CFRunLoopWakeUp() from another thread. The documentation suggests that removing or invalidating the last source would stop the runloop (ostensibly via a call to CFRunLoopWakeUp()). However, looking at the source verifies your findings, namely that CFRunLoopWakeUp() is not called implicitly as part of the CFRunLoopTimerInvalidate() or CFRunLoopRemoveTimer() calls. CFRunLoopStop(), however, does implicitly call CFRunLoopWakeUp(). Seems like you can either continue calling CFRunLoopStop(), or you can manually call CFRunLoopWakeUp() after removing/invalidating the timer. - Kevin _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... This email sent to site_archiver@lists.apple.com