So, to summarize my issues with threads on OS X:
1. pthread_testcancel() (and sleep() variants in Leopard) are cancel points, read() and perhaps other useful points are not. pthread_testcancel man page is incorrect in all versions of OS X. (does anyone have an accurate cancel point list?!?!)
2. read() cannot be made to return by interruption with a signal, although the man pages suggests a return code for that condition. (I was sending a SIGALRM with my own handler installed — is there a particular signal I need to send, perhaps without installing my own handler?)
3. pthread_mutex_unlock *does* sometimes work in a signal handler (where the lock was acquired in the thread before the signal.) It works in my simplified test case, I haven't nailed down why it complains "operation not permitted" in my real code.
4. Exceptions thrown during signal handling can't fall through and be handled by the thread (perhaps this is required behavior by standards, but it sounds like a nice feature — I don't see how letting the exception unwind past the signal handler call could be any worse than just aborting on the spot.)
5. I'm basically recreating the asynchronous cancel type.... because it's apparently not supported at all on OS X (even ignores explicit pthread_testcancel calls, much less exit from busy loop!)
6. Still haven't found a way to release resources referenced on the stack — C++ destructors are not called, exception handling is not triggered. (this causes memory leaks, invalid mutexes left locked, etc. The C++ exception handling is a much better mechanism than the pthread_cleanup_* functions, and currently they don't play well together)
These are all pretty glaring problems IMHO :(
FWIW, on linux, the results are:
1. works with read() at least, probably others like it says it will
2. same results (doesn't actually return EINTR)
3. same results (works for the simple test case)
4. Works just like I suggest it should — exception rolls through signal handler and elegantly triggers thread cancellation.
5. asynchronous partially supported, seems to be well handled if thread was at a cancelation point, but aborts with "terminate called without an active exception" if in the middle of a busy loop.
6. Works beautifully... note that with this and #1 in place, makes the hacks in 2-5 relatively moot even if they didn't work.
I'll attach the 6 test cases because misery loves company :(
As always, input appreciated! At this point I'm just mulling over different portability and functionality issues... perhaps this thread will be useful to others. (as in,
http://despair.com/mis24x30prin.html )
Thanks,
-ethan