Re: Cocoa multithreading in C (terrible idea, isn't it?)
Re: Cocoa multithreading in C (terrible idea, isn't it?)
- Subject: Re: Cocoa multithreading in C (terrible idea, isn't it?)
- From: Shaun Wexler <email@hidden>
- Date: Tue, 20 Dec 2005 15:47:33 -0800
On Dec 20, 2005, at 3:13 PM, John Stiles wrote:
You can't process events on a thread other than the main thread. As
you've found, it will not work and can die in a variety of ways.
With Cocoa/AppKit (and with most UIs), if something isn't
explicitly documented as being thread-safe, you must do it on the
main thread.
Normal user events should be processed on the app's main thread,
because you want them handled sequentially in time. There are
exceptions however, such as my app which captures HID events on a
high-priority thread for low-latency show control cue triggering via
hot-keys, dedicated HUI devices, etc.
For interactive threaded graphics processing, the main thread should
only determine what and how an event should be handled, possibly
perform some lightweight calculations, and then tell the drawing
engine(s) what to do with the new data. If the calculations are
intensive, that is a good thread candidate. If it's only the
submission of drawing commands, inevitably GL must internally
serialize them to the hardware, but if you're rendering to multiple
drawables, each with its own context, then those can certainly be
threaded for efficiency. Afterwards, you have to coordinate your
surface compositing bottleneck and synchronize with the windowing
system, basically back to single-threaded operations.
On Dec 20, 2005, at 3:07 PM, Christos Papachristou wrote:
I have implemented all thread interfaces: pthreads, Cocoa and
Carbon, and initialized the GLUT display system in the launched
threads.
I think you partially misunderstand how threading works. There are
several threading APIs, but all are layered atop the same primitive.
Pick the one API that matches your app. It looks like you have a
Cocoa app, so you should choose NSThread, which simply wraps
pthread. Write your application single-threaded first, get it
working, then PROFILE to determine if multithreading can add a
significant performance boost, such as if it can't sustain max
refresh rate of your display (60 Hz for LCD, 75+ Hz for CRT). Often
you'll find that you're GPU-bound rather than limited by the CPU.
NOTE: faster LCD's are coming soon, as well as multi-threaded
graphics drivers. I have an Acer 19" with <6 ms refresh (>167
fps)... alas, the Mac OS X drivers currently only support it up to 75
Hz.
--
Shaun Wexler
MacFOH
http://www.macfoh.com
"You can't write a good song about a whorehouse unless you' been in
one." -- Woody Guthrie
_______________________________________________
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