RE: question for CFRunLoopStop()
RE: question for CFRunLoopStop()
- Subject: RE: question for CFRunLoopStop()
- From: "Philip Lukidis" <email@hidden>
- Date: Mon, 8 May 2006 17:44:37 -0400
- 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:email@hidden]
Sent: Friday, May 05, 2006 6:30 PM
To: Philip Lukidis
Cc: email@hidden
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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden