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 | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.