Re: proposal: Thread Properties API

[Torvald Riegel <triegel at redhat dot com>]

On Thu, 2014-04-24 at 13:38 +0400, Konstantin Serebryany wrote:
> ================== Callback for thread exit  ==================
> Tools such as ASAN, MSAN and LSAN need to perform various cleanup
> actions just before a thread exits.
> 
> Currently these tools use an ugly hack to get notified about thread's
> destruction: call pthread_setspecific recursively
> PTHREAD_DESTRUCTOR_ITERATIONS times; when the
> PTHREAD_DESTRUCTOR_ITERATIONS-th call is made we consider the thread
> as dead. A cleaner interface would be much appreciated (not sure if it
> easy to do or at all possible)

GCC's libitm uses a similar hack, but checks whether transactions have
been used since the last round of pthreads TLS destruction.

> // Register callback to be called right before the thread is totally destroyed.
> // The callbacks are chained, they are called in the order opposite to
> the order they were registered.

I think we need a more detailed contract here.  What does "totally
destroyed" mean?  What's the requirements on the destruction code
running, especially regarding which other components can be used during
destruction.  For example, how would ASAN/MSAN/LSAN interact with libitm
if it would use this feature?

I would guess that we'd need some combination of "stick to limited set
of features during destruction" and possibly a multi-round destruction
to get the dependencies sorted (otherwise, we'd need the registration
order to perfectly match the logical dependencies during destruction).

> // The callbacks must be registered only before any threads were
> created, at most 8 callbacks can be registered.

Why did you include the former constraint?  Wouldn't this prevent some
uses of this feature?
Why at most 8 callbacks?  Arbitrary choice?

> // No signals may arrive during the calls to these callbacks;
> immediately after the last of these calls the thread is dead.
> void __libc_register_thread_exit_callback(void (*cb)());

What happens to those signals?  Or is it a requirement on the
program/... that they shouldn't get any?