Re: Where do asynchronous API do their "work"?
Re: Where do asynchronous API do their "work"?
- Subject: Re: Where do asynchronous API do their "work"?
- From: René van Amerongen <email@hidden>
- Date: Sun, 13 Nov 2005 10:23:19 +0100
Op 13-nov-2005, om 5:00 heeft Shawn Erickson het volgende geschreven:
On Nov 12, 2005, at 5:38 PM, email@hidden wrote:
As a rule of thumb, if you're going to work with the Cocoa API's
in an asynchronous fashion anywhere, it's wise to run the current
runloop periodically - manually, if you must. So your blocking
code need only do that once in a while to resolve your problem.
Not sure I fully agree with this advice (at least not as stated).
In general blocking or long running code should not be done on the
main thread but on a secondary thread or converted to use
asynchronous means.. If you keep such code off of the main thread
its run loop will service events[1] in a timely fashion keeping the
application responsive to the user (the main priority) and your
async operations flowing. In effect keeping your runloop going.
Using more threads for things can be your friend is you leverage
them right (each thread can have its own runloop allowing those to
be used instead of the main thread as a way to process certain
events/callbacks).
Do you know of a good ( coding ) sample about what your saying
( thread, own runloop, long code and status notification in Gui ).
I think I have to change something in my design,
Thanks
Rene
-Shawn
[1] System events and possibly callbacks/events/timers from some of
the async things you are doing.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40xs4all.nl
This email sent to email@hidden
_______________________________________________
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