[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 27 Jan 2020 21:37:59 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Cc: Rich Felker <dalias@...c.org>, Simon <simonhf@...il.com>
Subject: Re: Bug report: Reproduction of seg fault caused by musl
thread creation race condition
* Simon <simonhf@...il.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.
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.
