[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140830051254.GI12888@brightrain.aerifal.cx>
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.
