site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Hi, Lassi _______________________________________________ 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... Is it *at all possible* to unlock a mutex following the interruption of a thread on Tiger? (I haven't tried this on Leopard yet -- since I don't need to do the signal hack there, hopefully this is moot) Basically, I'm reading from a socket, and need a way to kill the thread if there's no response. But I also need to maintain a lock on the socket while I'm waiting for a response so other tasks don't try to send their own queries. I'm polling relatively frequently, so I don't want to have to take the lock, launch a new thread, and monitor the other thread every time. (this is a real-time task with a hardware device) Is there any particular reason you don't do the semi-standard unix method of using select() or equivalent on your socket together with a pipe, and then write a byte to the other end of the pipe from whoever wanted to stop the thread in the first place? No messing with signals needed. On a related note, don't use pthread_mutex_* from a signal handler if you use the same mutex outside signals in the same thread. You may not be allowed to enter pthread_mutex_* twice in the same thread, even if the mutex is recursive. Let's say the socket reader quits at just the right time and enters pthread_mutex_*, and just then your signal arrives, and also attempts to execute pthread_mutex_*. Now your program would have entered the mutex twice in the same thread. On some systems this results in a failure or a dead-lock. This email sent to site_archiver@lists.apple.com