Re: pthreads and CF runloops (possibly slightly OT)
Re: pthreads and CF runloops (possibly slightly OT)
- Subject: Re: pthreads and CF runloops (possibly slightly OT)
- From: email@hidden (Hado Hein)
- Date: Sat, 12 Nov 2005 16:20:38 +0100
- Organization: handmade !
Garth Cummings <email@hidden> wrote:
> I can guess that they're trying to point out that the Cocoa threading
> model, for example, can explicitly run any code on the main thread
> even if initiated from another thread. If you are using naked
> pthreads and want to do UI, you'd have to work out your own
> rendezvous mechanism with your main thread to have it run the UI.
Hoi,
I want to jump in here. One thing (apparently more in Aqua ;-) is that I
have in mind only to draw from the main thread (aka AppRunLoop).
Do I understand the above right in the way that a secondary thread could
append some source to the main loop and let the main loop then execute
some drawing (which it is not allowed in its own thread).
For Philip,
I experimented with the runloops some time ago. My "feel easy with
pthreads" skeleton goes a simple way. In the pthread parameter the
thread gets some preallocated storage (don't alloc persistent from the
thread this brings trouble on dp machines vs. cpu cache).
In the threads funtion I get the master pointer, the threads runloop and
some other vals I want to have in any thread.
Since the threads storage is prealloced I now can dig that storage and
install sources in any runloop the apps has. And of course dealloc them.
Like this you don't need bitflags in your global storage. Especially
toggle menu items (checked or not) can be handled safely in the main
loop with iterating installed handlers in a secondary runloop.
Oh yes, and on onet hing you can rely also: pthread_cancel them from the
main loop and the secondary runloops will automaticalley be stopped
tidyly. You just need to zero your stored references.
--
Hado Hein, Berlin, Fed.Rep. of Germany
sip: ++49/30/916488488
http://www.batchmaker.de (software authoring, including stage lighting)
_______________________________________________
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