[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140905160248.GL23797@brightrain.aerifal.cx>
Date: Fri, 5 Sep 2014 12:02:48 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: In-progress stuff, week of Sept 1
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
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.
