From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5980 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: sem_getvalue conformance considerations Date: Sat, 30 Aug 2014 01:12:55 -0400 Message-ID: <20140830051254.GI12888@brightrain.aerifal.cx> References: <20140827023338.GA21076@brightrain.aerifal.cx> <1409123141.4476.18.camel@eris.loria.fr> <20140827074310.GK12888@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1409375596 10253 80.91.229.3 (30 Aug 2014 05:13:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 30 Aug 2014 05:13:16 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5987-gllmg-musl=m.gmane.org@lists.openwall.com Sat Aug 30 07:13:09 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XNayL-0007MC-0U for gllmg-musl@plane.gmane.org; Sat, 30 Aug 2014 07:13:09 +0200 Original-Received: (qmail 14116 invoked by uid 550); 30 Aug 2014 05:13:08 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 14105 invoked from network); 30 Aug 2014 05:13:07 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:5980 Archived-At: 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