Subj : Re: atexit handler: pthread_cancel, pthread_testcancel, pthread_join problem
To   : comp.programming.threads
From : loic-dev
Date : Thu Aug 18 2005 05:49 am

Salut Joe,

> I think exit() just terminates all the threads so there are no threads to
> cancel or join.  You should probably get EINVAL though unless something
> somewhere says you can have undefined behavior.  The core dump is probably
> from the thread id being invalid.  Thread id's are opaque handles and on
> Linux appear to be pointers to thread local storage and you tend to get core
> dumps when no longer valid thread id's are dereferenced.

It is true that, potentially, exit() may invalidate thread's ID before
calling the atexit handler. However, accordingly to SUS:

<copy>
The exit() function shall first call all functions registered by
atexit(), in the reverse order of their registration, except that a
function is called after any previously registered functions that had
already been called at the time it was registered. Each function is
called as many times as it was registered. If, during the call to any
such function, a call to the longjmp() function is made that would
terminate the call to the registered function, the behavior is
undefined.
</copy>

So, from my understanding, OP code is legal and should work.

( Note aside. In the case you join a thread with an invalid thread ID,
the function fails with ESRCH. )


> exit isn't a clean way to terminate threads so the obvious answer is don't
> use it if you want clean thread termination.

I share Joe's opinion here. It doesn't make a lot of sense to register
an atexit handler that cancels the thread. The function exit() does
just that. If you need a cleaner termination mechanism, you might want
to implement another solution (based, for instance, on a condition
variable). 

Regards,
Loic.

.