[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1407319247.24324.284.camel@eris.loria.fr>
Date: Wed, 06 Aug 2014 12:00:47 +0200
From: Jens Gustedt <jens.gustedt@...ia.fr>
To: musl@...ts.openwall.com
Subject: Re: PATCH: don't call cleanup handlers after a regular
return from the thread start function
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.
> Yes. But my point is that crashing in libc code is probably the least
> of your worries here. It's more likely that the crash (or at least
> deadlock) occurs in application code from cancelling a thread while
> it's in an inconsistent state, holds locks, etc. without a chance to
> do cleanup (since the target thread was not designed for
> cancellation).
I am not sure. With C11 threads as they are designed now, we will have
more dynamic initialization than with pthreads. This is for the simple
reason that there is no guaranteed static initialization for mutexes
or conditions. Either doing the initialization in `main` before
starting threads or once_call is the only (official) way to
go. Debugging an application that crashes during such a dynamic
startup (or the corresponding shutdown) can be really nasty.
> 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
> This should really all be a topic for discussion with the Austin
> Group for how POSIX should be aligned with C11 threads, though, and
> I'm hesitant to make any public behaviors for musl that look like
> API guarantees (rather than "this is the way it works for now, but
> don't depend on it, since it's going to change when the next issue
> of POSIX is published") at this time.
Yes, this shouldn't be guaranteed unless POSIX mandates it. But it
could documented as an implementation and version dependent choice.
Jens
--
:: INRIA Nancy Grand Est ::: AlGorille ::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536 ::
:: :::::::::::::::::::::: gsm France : +33 651400183 ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::
Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)
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.
