Am Mittwoch, den 06.08.2014, 05:35 -0400 schrieb Rich Felker: > BTW one "safety" we currently have is that pthread_cleanup_pop does > not just "pop one cleanup context"; it resets the context to the one > that was in effect at the time the corresponding push was called, > potentially popping multiple contexts if one or more pop was skipped > via illegal returns or similar. In principle a check-and-crash could > be added asserting that self->cancelbuf == cb before doing this, but > I'm mildly hesitant to add conditionals to something that should be a > fast-path. You would have my +1 for that. Everyone should be aware that cleanup push/pop comes with a cost and one conditional jump really doesn't add much to the cost. > Yes. But my point is that crashing in libc code is probably the least > of your worries here. It's more likely that the crash (or at least > deadlock) occurs in application code from cancelling a thread while > it's in an inconsistent state, holds locks, etc. without a chance to > do cleanup (since the target thread was not designed for > cancellation). I am not sure. With C11 threads as they are designed now, we will have more dynamic initialization than with pthreads. This is for the simple reason that there is no guaranteed static initialization for mutexes or conditions. Either doing the initialization in `main` before starting threads or once_call is the only (official) way to go. Debugging an application that crashes during such a dynamic startup (or the corresponding shutdown) can be really nasty. > One "safe" approach might be for call_once to simply block > cancellation for the duration of the call. In fact C11 threads could > even start with cancellation blocked, unless of course POSIX mandates > otherwise in the next issue. right, good idea, I'll give it a thought > This should really all be a topic for discussion with the Austin > Group for how POSIX should be aligned with C11 threads, though, and > I'm hesitant to make any public behaviors for musl that look like > API guarantees (rather than "this is the way it works for now, but > don't depend on it, since it's going to change when the next issue > of POSIX is published") at this time. Yes, this shouldn't be guaranteed unless POSIX mandates it. But it could documented as an implementation and version dependent choice. Jens -- :: INRIA Nancy Grand Est ::: AlGorille ::: ICube/ICPS ::: :: ::::::::::::::: office Strasbourg : +33 368854536 :: :: :::::::::::::::::::::: gsm France : +33 651400183 :: :: ::::::::::::::: gsm international : +49 15737185122 :: :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::