[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20140806101254.GW1674@brightrain.aerifal.cx>
Date: Wed, 6 Aug 2014 06:12:54 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: PATCH: don't call cleanup handlers after a regular return
from the thread start function
On Wed, Aug 06, 2014 at 12:00:47PM +0200, Jens Gustedt wrote:
> Am Mittwoch, den 06.08.2014, 05:35 -0400 schrieb Rich Felker:
> > BTW one "safety" we currently have is that pthread_cleanup_pop does
> > not just "pop one cleanup context"; it resets the context to the one
> > that was in effect at the time the corresponding push was called,
> > potentially popping multiple contexts if one or more pop was skipped
> > via illegal returns or similar. In principle a check-and-crash could
> > be added asserting that self->cancelbuf == cb before doing this, but
> > I'm mildly hesitant to add conditionals to something that should be a
> > fast-path.
>
> You would have my +1 for that. Everyone should be aware that cleanup
> push/pop comes with a cost and one conditional jump really doesn't add
> much to the cost.
Indeed. And it should be a 100% predictable jump. My main concern then
is whether we can ensure that it doesn't have false-positives (crashes
for valid-but-ugly usage).
> > One "safe" approach might be for call_once to simply block
> > cancellation for the duration of the call. In fact C11 threads could
> > even start with cancellation blocked, unless of course POSIX mandates
> > otherwise in the next issue.
>
> right, good idea, I'll give it a thought
The latter probably doesn't help, since obviously the main thread
can't start with cancellation disabled, and call_once is likely to be
called from a thread started with pthread_create in applications where
the C11 thread code is just in a thread-safe library that doesn't
itself make the threads that are doing the calling.
On the other hand, having call_once block cancellation should
eliminate the problem, but there's a chance POSIX would not allow that
behavior.
We should really make a summary of the issues that have come up in
this thread to deliver for consideration when the Austin Group works
on aligning POSIX with C11. There's a much better chance that they'll
avoid specifying things that would be problematic if there's
documented discussion of the issues that arise.
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.
