Re: RunLoops
Re: RunLoops
- Subject: Re: RunLoops
- From: Joseph Kelly <email@hidden>
- Date: Sat, 5 Nov 2005 15:16:28 -0800
On Nov 5, 2005, at 2:41 PM, Martin Tauber wrote:
Well this is how the runloop could handle NSPort or NSConnection
sources. But then in the meantime it could not react to other event
sources (like mouse clicks for example). Is this why the runLoop
can (or must?) be run in different modes? But which mode would then
except which source?
My very limited experience is showing that the run loop associated
with the main thread and threads started w/ NSThread are responding
to mach_msg_port (i.e. usb and bluetooth completion and notification
callbacks) and ui sources just fine. I don't know if this would
address your particular application.
(I'm even able to fake a synchronous call on an async operation by
using CFRunLoopRun() and CFRunLoopQuit(), but that's another story...)
On the other hand when I was debugging my application I saw a
thread that I didn't create. Now my thinking was that if there is
more than one event source (for example NSPorts and mouseEvents)
the runLoop is listening to, maybe it delegates the listening to
threads and then just waits for the threads to tell the runLoop
that a event arrived.
This would require the thread to busy-poll or else add a run loop
source which would get fired when the worker thread was finished. As
long as the operation is async, why not just have the completion
occur on the issuing thread/runloop instead of having to manage one
more run loop source?
Cocoa seems to create threads for updating the UI, esp when I've got
an animated control running. Maybe this is the thread you saw?
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
| References: | |
| | >RunLoops (From: Martin Tauber <email@hidden>) |