Re: Calling other functions while concurrently calling exit?

[Rich Felker <dalias at aerifal dot cx>]

On Tue, Sep 22, 2015 at 09:42:08PM +0200, OndÅej BÃlka wrote:
> On Sat, Sep 19, 2015 at 10:26:37AM -0400, Rich Felker wrote:
> > On Sat, Sep 19, 2015 at 12:10:41PM +0200, OndÅej BÃlka wrote:
> > > On Sat, Sep 19, 2015 at 08:48:21AM +0200, Andreas Schwab wrote:
> > > > "Carlos O'Donell" <carlos@redhat.com> writes:
> > > > 
> > > > > Is it spelled out anywhere in POSIX or ISO C that calling
> > > > > other functions concurrently with exit is going to result
> > > > > in undefined behaviour?
> > > > 
> > > > exit must be thread-safe, except that calling it more than once is
> > > > undefined.
> > > > 
> > > Wait, we don't do sane thing and first cancel all other threads before doing anything?
> > 
> > You cannot cancel threads that are currently running code that was not
> > designed to be cancellable. Doing so is extremely dangerous.
> > 
> And could you explain how that is different from situation now where
> exit will terminate all threads so you will get inconsistent state
> anyway?

There is no further code running to produce undefined behavior when it
tries to access a thread that disappeared out from under it. Yes,
persistent state that exists past process termination (shared memory
segments, files, etc.) could be left inconsistent by asynchronous
exit, but this cannot lead to catastrophic invalid memory
access/corruption in the exiting process since it no longer exists.
Also, on a conforming implementation you can avoid this issue by using
flockfile() to produce 'atomic' stdio transactions; exit() either
allows the whole transaction to complete, or none of it at all. (Of
course using _exit instead would break that.)

> > > How otherwise we would run tls destructors in context of correct thread?
> > 
> > TLS destructors only run when the thread exit, either by being the one
> > to call exit or by exiting as a thread (e.g. pthread_exit). This is
> > all specified.
> > 
> While true its bad design, C++ programmers would be often surprised
> that destructors that close files, unlock process shared locks or so
> don't run.

In well-designed idiomatic C++ code, the dtors that run just before or
when exit is called will cascade down to the objects representing all
your live threads, and will request that they exit and join them.

Of course the reality of real-world C++ is much different... :(

Rich