Re: [musl] Bug report: Reproduction of seg fault caused by musl thread creation race condition

[Szabolcs Nagy <nsz@port70.net>]

* Simon <simonhf@gmail.com> [2020-01-27 11:59:24 -0800]:
> > Upon successful completion, pthread_create() shall store the ID
> >
> 
> "Upon successfully completion" is somewhat vague wording IMO which could
> result in misinterpretation? You seem to have interpreted it as "Upon
> function completion", but surely if clone() succeeds, and the new thread
> starts running, then there is already "successful completion" even before
> pthread_create() has returned to caller?

there is no ambiguity here.

completion of a function call, such as pthread_create,
is well defined and it's the point that's sequenced
after the call returns, you have to synchronize with
that point to read the value from another thread.

> This seems more specific than "Upon successful completion" but still
> doesn't exactly tie down whether the thread ID should be written before the

the point is to not tie the behaviour down so you cannot
rely on it, this allows implementation freedom.

> I checked the glibc pthread_create() implementation and it appears to set
> the thread ID before the new thread executes. So from that POV any code
> using glibc relying on this is arguably non-portable, but not racy since
> there is no race with the glibc implementation?

it is racy because glibc gives no guarantee, i.e. an
update may change this implementation internal detail.