site_archiver@lists.apple.com Delivered-To: Darwin-dev@lists.apple.com Hi, mach_port_t machThread = pthread_mach_thread_np(fThread); thread_terminate(machThread); So: (A) Give it the semaphore it wants (B) Signal it with pthread_kill() No. -- Terry _______________________________________________ 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... On May 30, 2008, at 1:32 AM, Stéphane Letz wrote: We have a thread that locks a mutex and terminates, either itself or being "killed" by another thread. If this thread is "cancellable" using the phread API pthread_cancel()/pthread_join(), then we can possibly use pthread_cleanup_push/pthread_cleanup_pop at the appropriate place to properly unlock the mutex at termination stage. This seems to work correctly. But in some cases the thread is waiting on a low-level mach semaphore (we are directly using semaphore_wait/semaphore_signal kind of API) and the thread cannot be cancelled using pthread_cancel()/pthread_join(). Thus we use the following kind of code to terminate the thread: but then is seems that the pthread_cleanup_push/pthread_cleanup_pop method to unlock the mutex does not work anymore.... and we have a deadlock later on. 1) Is there a way to cancel a thread waiting using semaphore_wait using standard pthread API? So that thread_cleanup_push/ pthread_cleanup_pop can be used? 2) Is case 1) is no, is there any other method to add cleanup handlers when using low-level thread_terminate API? The pthread state is distributed between kernel (the backing Mach thread) and user space (the pthread itself). Cleanup handlers are on the pthread side. So if you terminate the kernel thread out from underneath the user space thread, it never returns to user space to permit the cleanup handlers to run to completion. This email sent to site_archiver@lists.apple.com