Re: PATCH: don't call cleanup handlers after a regular return from the thread start function

[Jens Gustedt <jens.gustedt@inria.fr>]

[-- Attachment #1: Type: text/plain, Size: 4483 bytes --]

Hello,

Am Dienstag, den 05.08.2014, 15:41 -0400 schrieb Rich Felker:
> On Tue, Aug 05, 2014 at 09:06:16PM +0200, Jens Gustedt wrote:
> > But I have another reason for wanting that, future compatibility with
> > C threads. Programs that are written for C threads will not be aware
> > of such interdictions. Concretely in our case of my C thread v3 patch
> > a user can longjmp from a once-init-handler (written by her or him)
> > through pthread_once (in libc, for musl with pthread_cleanup_push) to
> > the thread start function (again user code) and then return from
> > there. (All of this seems to be allowed by POSIX)
> 
> Such a longjmp is UB unless it's explicitly permitted by the standard
> -- same as longjmp out of qsort.

Which standard are you refering to? I don't find any mention of such a
thing in the C standard. In the contrary, I find a lot of contexts
where longjmp is explicitly forbidden, such as at_exit and
similar. bsearch, qsort and call_once are not among these, and there
is no general mention of longjmp and "callback" contexts.

(I just find your second message. I don't find the "shall return" for
the comparison function as binding to exclude longjmp, for bsearch
this might even be tempting. For call_once, I agree, it is probably
lack of consideration.)

> There's no guarantee to a function
> called as a callback from the standard library that the calling
> function does not have internal state which would be left in an
> inconsistent state by longjmp'ing out.

Don't get me wrong, it isn't a brilliant idea to do longjmp from such
callbacks, but I don't see that you have an argument here. The
definition of setjmp/longjmp clearly states which circumstance make it
UB to use them. For the rest, this *defines* the behavior for all
other contexts, including callbacks, unless explicitly forbidden.

> If call_once is explicitly required to support longjmp,

It is not explicitly forbidden and I think this is sufficient to allow
for it.

I don't know about the equivalent for the pthread tools, though.

> then a separate implementation of call_once is needed for C11

yes

> without cancellation support.

no, it needs cancellation support that doesn't use local objects, see
below.

> However I doubt this usage is supported, since
> the state of the once_flag would have to be specified for such
> interrupted calls, and I see no such specification.
> 
> > I consider to not execute the cleanup handlers a little bit more
> > friendly than executing them.
> 
> musl does not do either. It's simply UB. At the point where you're
> claiming the cleanup handler is executed, the pointer being
> dereferenced is to an object whose lifetime has ended, so it's not
> even making a call to the cleanup handler but simply invoking UB.

Aren't you playing a bit with words, here? Fact is, that the handler
might be called in real life. We are not obliged to be nasty when (and
if!) the user is invoking UB.

For the case of pthread_once or call_once, we could get away with it
by having the `struct __ptcb` static at that place. The caller of the
callback holds a lock at the point of call, so there would be no race
on such a static object.

I will prepare a patch for call_once to do so, just to be on the safe
side. This would incur 0 cost.

The same could be used for pthread_once.

> > Another possibility would be to split the behavior
> > 
> >  - abort for pthreads (this is nicer than executing the handlers or
> >    than silently ignore them)
> > 
> >  - ignore for C threads
> 
> There's no way it can happen for C threads unless they're actually
> using pthread_cleanup_push, and the relevenat code that might be
> returning is aware of POSIX and the reules for use of
> pthread_cleanup_push.

I don't think it is as simple as that. From C you might use a third
party library that on a specific platform uses pthread features under
the hood. E.g gcc's libatomic is such a candidate, they are using
pthread_mutex_t without telling you. OpenMP also comes in mind. And
who knows want the future will bring on such mixed platforms.

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 ::



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]