Re: Mach Thread API
Re: Mach Thread API
- Subject: Re: Mach Thread API
- From: Quinn <email@hidden>
- Date: Mon, 12 Jul 2004 12:04:05 +0100
At 18:05 +0200 7/7/04, Christoph Ndgeli wrote:
1. Calling pthread_testcancel() during the
thread. If I want to kill, call pthread_cancel
followed by a broadcast on the condition
variable in case the thread is waiting. I think
it's a little annoying always calling
pthread_testcancel() all the time.
There's an even easier solution. Have your game
thread poll a global variable. When your main
thread wants to quit the game thread, set the
global and broadcast the condition (to wake up
the game thread if it's blocked). It's fast and
safe.
You can avoid excessive performance overhead by
placing your tests of the global in a part of the
code that runs about ten times a second;
cancellation has to be responsive, but not /that/
responsive.
Another option would be to use per thread signals
combined with setjmp/longjmp. However, as Jim
said, jumping out of an OS routine will cause you
a world of pain. So you should only do this if
you can guarantee that that game thread never
calls the OS (which is surprisingly difficult to
do, consider malloc).
2. Forget about posix threads and work directly
with Mach threads (thought they look a little
complicated comparing to the pthreads => Is
there any example code out there?).
Don't do this. pthreads is where Apple places
our compatibility stake in the ground. The
following quote from Technote 2028 is good advice.
User-space processes should not create Mach threads directly.
-- <
http://developer.apple.com/technotes/tn/tn2028.html#MacOSXThreading>
S+E
--
Quinn "The Eskimo!" <
http://www.apple.com/developer/>
Apple Developer Technical Support * Networking, Communications, Hardware
_______________________________________________
darwin-kernel mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/darwin-kernel
Do not post admin requests to the list. They will be ignored.