Date: Sat, 30 Aug 2014 01:12:55 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: sem_getvalue conformance considerations On Sat, Aug 30, 2014 at 02:51:35AM +0400, Alexander Monakov wrote: > Hi, > > To begin, I have a few questions regarding cancellation (please excuse > deviating from topic for a while): > > 1. It looks non-conforming not to act on pending cancellation in uncontended > sem_wait (or any cancellation point that does not invoke a syscall, for that > matter; nsz pointed out that many instances should already be handled, but > pthread_join for instance seems to miss explicit timedwait). A bug? Probably so. > 2. I had trouble understanding cancel_handler. What is re-raising > SIGCANCEL at the end for? It's for the case where the signal arrives during a signal handler that does not itself contain cancellation points, but which has interrupted a cancellation point. In this case, we want cancellation to re-trigger after the signal handler returns. This is achieved by re-raising the signal, but blocking the signal in the ucontext that cancel_handler is about to return to (if it weren't blocked there, re-raising it would make an infinite loop). When the next-level-up signal handler returns, it unblocks the signal again and it gets delivered, and cancel_handler runs again and can evaluate whether it's at a cancellation point. > 3. My understanding is that for deferred cancellation, ideally you'd want > SIGCANCEL to be delivered only as interruptions to syscalls --- that would > eliminate some scaffolding around syscall_cp including IP range check in > cancel_handler, correct? No, that's impossible to eliminate. Any solution without it has a race condition where cancellation that arrives after the check-before-syscall but before actually enterring the syscall gets lost. And that's even assuming an interrupting signal can be used for cancellation, which is false. An interrupting signal would also interrupt blocking syscalls which are not cancellation points, thereby messing up program semantics. > 4. If the above could be provided, it would be possible to guarantee that > pthread cancellation cleanup is executing in a signal handler context only for > asynchronous cancellation. I'd like that for my sem unwait. Too bad? Not possible. But I've already described the cancellation mode I want to add whose observable behavior is like this. I'll address the actual semaphore ideas later. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.