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: Christos Papachristou <email@hidden>
- Date: Wed, 21 Dec 2005 14:20:02 +0200
On 21 Δεκ 2005, at 1:47 ΠΜ, Shaun Wexler wrote:
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.
The scheme for the library is to handle all events and user requests,
as well as drawing routines in the secondary thread. Everything works
well when the appllication defines an int alt_main(argc,argv) and the
library the real main, which launces the application on a secondary
thread and the window system remains on the primary one. Yet this is
not very elegant.
How did you manage to capture the HID events in your app?
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.
I have tried all three APIs, in case the Cocoa and Carbon ones would
set the interrelationships between the the Aqua interface and the
objects correctly, a task that pthreads does not. The GLUT library
(and SDL) need an event loop, which I dont want to run in the main
thread, because it would not fit in a simple sequential program.
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