This is the mail archive of the
mailing list for the glibc project.
Re: proposal: Thread Properties API
- From: Konstantin Serebryany <konstantin dot s dot serebryany at gmail dot com>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: Roland McGrath <roland at hack dot frob dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 25 Apr 2014 14:58:39 +0400
- Subject: Re: proposal: Thread Properties API
- Authentication-results: sourceware.org; auth=none
- References: <CAGQ9bdxY1AZtcqZ6k1c+kenmTkWU01YQA6LZMzFGdfX5bUe62Q at mail dot gmail dot com> <20140422195129 dot 1BC492C39C5 at topped-with-meat dot com> <CAGQ9bdxTQVeHr31YSFeZbKAzhNSC2HOTeTE=jxaK_y3=UFaCpQ at mail dot gmail dot com> <1398350733 dot 3155 dot 5755 dot camel at triegel dot csb>
On Thu, Apr 24, 2014 at 6:45 PM, Torvald Riegel <email@example.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).
> What's the requirements on the destruction code
> running, especially regarding which other components can be used during
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
>> // 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