Re: pthreads and CF runloops (possibly slightly OT)
site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Organization: handmade ! User-agent: MacSOUP/D-2.7 (Mac OS X version 10.3.9) Garth Cummings <gcummings@apple.com> 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 (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... This email sent to site_archiver@lists.apple.com
participants (1)
-
applediscloseï¼ batchmaker.de