site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com thanks, -ethan _______________________________________________ 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... However, when I try to call pthread_mutex_unlock from the cleanup function that results from the eventual pthread_testcancel, it returns an error "Operation not permitted". Sigh... I have to take this back — testing in a simplified piece of test code does seem to work on both 10.4 and 10.5. So I'm not sure what's going on there with my "real" code. 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. Unfortunately, I'm given an std::iostream for the input, so I can't select on that :( I suppose things could be re-engineered to pass a file descriptor (or hacked to extract the file descriptor from the iostream), but that doesn't solve the general problem for other blocking system calls which aren't socket based (e.g. wait, sigwait, pthread_join, etc) I did realize however, that read() has a EINTR error return code, so instead of trying to unlock within the signal handler itself, perhaps I could just make the handler a no-op, and then test for the error code following the read(). However, in its infinite wisdom, the system resumes the read and doesn't bat an eye at the signal coming and going, so this idea never actually interrupts the read(), nor causes the unlock and exit to occur. I've been doing some more testing and will reply to myself in my original thread with some updates/summary... This email sent to site_archiver@lists.apple.com