On Wed, Aug 15, 2012 at 05:47:47PM -0700, Thomas DiModica wrote: > My understanding is that pthread_cond_wait is a cancellation point. > It achieves this by entering asynchronous cancellation mode before blocking. > > I don't see, however, any code that checks for a pending cancellation when > we enter the function. As far as I can tell, the implementation is that > pthread_cond_wait is a cancellation point if and only if the thread is > canceled while it is blocked.
It seems so, yes. > Right now, I can't think of any solution involving checking for cancellation > that doesn't include a potential gap between checking for cancellation and > entering asynchronous cancellation mode. My opinion is that the implementation shouldn't rely on switching to async mode, and rather add explicit cancellation tests. This would require pthread_cancel be modified to wake the target thread in deferred mode. > PS Non-informative: setcanceltype in the cleanup function appears to > be in the wrong place. Shouldn't it be the first thing to happen? Spin lock > and spin unlock aren't async-cancel-safe, right? So, if we are in cleanup, > lock the lock, and someone cancels us: async-cancellation injects a > call to pthread_exit, where we call cleanup again and deadlock trying > to lock a lock we hold. That's not possible. The cleanup function is called from pthread_exit, which disables cancellation, whichever type is set. This call in the cleanup callback is meant to restore the type on entry in case no cancellation occurred. -- Richard Braun
