From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6089 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: In-progress stuff, week of Sept 1 Date: Fri, 5 Sep 2014 12:02:48 -0400 Message-ID: <20140905160248.GL23797@brightrain.aerifal.cx> References: <20140905011442.GA26136@brightrain.aerifal.cx> <20140905015729.GI10361@port70.net> <20140905084734.GJ23797@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 1409932989 15411 80.91.229.3 (5 Sep 2014 16:03:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 5 Sep 2014 16:03:09 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6102-gllmg-musl=m.gmane.org@lists.openwall.com Fri Sep 05 18:03:02 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 1XPvyX-0006Kr-VL for gllmg-musl@plane.gmane.org; Fri, 05 Sep 2014 18:03:02 +0200 Original-Received: (qmail 26598 invoked by uid 550); 5 Sep 2014 16:03:00 -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 26573 invoked from network); 5 Sep 2014 16:03:00 -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:6089 Archived-At: On Fri, Sep 05, 2014 at 01:07:35PM +0400, Alexander Monakov wrote: > On Fri, 5 Sep 2014, Rich Felker wrote: > > > sem_wait/pthread_join cancellation point in non-blocking case > > > > Fixed. > > On IRC there was an agreement that not testing cancellation unless an actual > syscall is performed is sensible, after I mentioned that cancellation is > similarly missing in glibc sem_wait as well. I wouldn't say an agreement. There was some sentiment to the effect, but obviously it doesn't conform to the requirements of the standard. Less obviously, it can lead to unbounded delays acting on cancellation in cases like producer/consumer uses where data is being produced so fast that the consumer almost never has to wait. > The current wording of the standard is not ambiguous to me though, and forbids > such elision. > > Rich, would you raise this for an explicit consideration with the Austin group? I'm not sure it's worth, or even advisable, trying to change. It's hard to specify exactly when omission of acting on cancellation would be permitted without referring to terms that aren't really defined, and I think it would yield less-useful behavior for applications. On the other hand, it could make a considerable performance difference to implementations where accessing TLS is costly (e.g. on mips). So I think it could at least be a topic of further consideration. Rich