Re: proposal: Thread Properties API

[Konstantin Serebryany <konstantin dot s dot serebryany at gmail dot com>]

On Thu, Apr 24, 2014 at 6:45 PM, Torvald Riegel <triegel@redhat.com> wrote:
> 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?

That's indeed tricky to define.
There is certainly a point of time when thread is still alive (e.g.
the 4-th tsd destructor),
and then there is a another point when it is dead-dead-dead (e.g. when
it's stack is unmaped or reused by another thread).
Suggestions?

> What's the requirements on the destruction code
> running, especially regarding which other components can be used during
> destruction.

No libc calls in the destruction code.

>  For example, how would ASAN/MSAN/LSAN interact with libitm
> if it would use this feature?
Never thought about libitm<=>*san interaction. Do you expect any problem there?

>
> 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?

8 is as good a number as 10 or 16. It has to be small constant to
simplify implementation.

>
>> // 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?

Can't we simply ignore all signals in the thread after some point
(like pthread_sigmask)?