RE: question for CFRunLoopStop()
RE: question for CFRunLoopStop()
- Subject: RE: question for CFRunLoopStop()
- From: "Philip Lukidis" <email@hidden>
- Date: Fri, 5 May 2006 15:20:36 -0400
- Thread-topic: question for CFRunLoopStop()
Thanks for your reply.
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."
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?
Finally, I was using pthread_join as a precautionary measure only, that
is just to make sure that after the child had been ordered to quit, that
it had fully exited (and then I could clean up its resources).
thanks for your reply,
Philip Lukidis
-----Original Message-----
From: Kevin Van Vechten [mailto:email@hidden]
Sent: Friday, May 05, 2006 2:33 PM
To: Philip Lukidis
Cc: email@hidden
Subject: Re: question for CFRunLoopStop()
On May 5, 2006, at 8:46 AM, Philip Lukidis wrote:
> Hello. I hope that I'm posting this to the correct list.
Yep.
> Concerning CF, I was wondering if the following scenario is correct:
> A "parent" thread creates a child thread via the pthread library.
> The child thread has only 1 runloop source on it (a timer in fact),
> and once the timer is applied onto the child runloop by the child
> itself, the child proceeds to call CFRunLoopRun() on itself. Now
> the parent is responsible for running down this child on demand.
> Can the parent rundown the child by:
I'm not sure what you mean by "rundown," but I'll assume you mean
stop the child's runloop.
> -invalidating the timer (via CFRunLoopTimerInvalidate())
> -removing the timer (via CFRunLoopRemoveTimer())
It's my understanding that a RunLoop will stop running when it has no
more valid sources or timers to listen to. So if there is only one
timer in the run loop, either of these would accomplish your goal.
> -calling CFRunLoopIsWaiting() in a while loop until it returns
> true (which indicates that all callbacks have drained and that it
> is waiting again, but of course since the timer was invalidated it
> can never be called again). Of course I should NOT holding a
> resource which the callback might need in order to execute and exit.
While I'm sure you could make something like this work, it's pretty
contrived.
> -calling CFRunLoopStop()
Yes, this will stop the run loop (even if it still has valid sources).
> -calling pthread_join() on the pthread
I don't think this will stop the run loop. Instead, it will block
the parent thread until the child thread exits.
> Can this also be extended to other runloop sources, by using
> CFRunLoopSourceInvalidate() instead of CFRunLoopTimerInvalidate(),
> and CFRunLoopRemoveSource() instead of CFRunLoopRemoveTimer()?
For sources that are of type CFRunLoopSourceRef, yes.
> If these procedures are incorrect, why so, and what are the
> alternatives?
I don't see any of the above as "alternatives." In your case, with
only one runloop source, CFRunLoopTimerInvalidate(),
CFRunLoopRemoveTimer(), and CFRunLoopStop() all have the same end-
result.
However, this is a consequence of a simple example, and not generally
true. Invalidating and removing a source have different semantics.
For example, you may want to invalidate a source (no matter how many
runloops may be using it), or alternatively you may want to remove a
source from a particular runloop but keep it as a source in another
runloop (or perhaps add it back to the same runloop at a later
time). Stopping a runloop doesn't affect any of the sources, so it
can be restarted at a later time in the same configuration that it
was in originally.
- 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