This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Thread-local support for non-POD data objects
- From: Rich Felker <dalias at aerifal dot cx>
- To: Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>
- Cc: Siddhesh Poyarekar <siddhesh at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 12 Jul 2013 23:10:51 -0400
- Subject: Re: Thread-local support for non-POD data objects
- References: <20130712172128 dot GC32671 at spoyarek dot pnq dot redhat dot com> <20130712201036 dot GD29800 at brightrain dot aerifal dot cx> <CAAHN_R2+dYSwJa6PCfumeYc17f8Xni7jhXcHnvyCmpLKZMLVzg at mail dot gmail dot com>
On Sat, Jul 13, 2013 at 01:57:14AM +0530, Siddhesh Poyarekar wrote:
> On 13 July 2013 01:40, Rich Felker <dalias@aerifal.cx> wrote:
> > Why is this needed in libc at all? My understanding is that the
> > thread-local ctors run when the C++ thread-creation function is used,
> > because pthread_create is called with a C++-implementation-internal
> > start function wrapping the application-provided start function. If
> > this is correct, then the start function provided by C++ could simply
> > use pthread_cleanup_push to install a cleanup handler that runs the
> > dtors, and run them manually with pthread_cleanup_pop(1) if the
> > application's start function returns. This would cover both
> > cancellation and pthread_exit or equivalent.
> >
> > Am I missing some obvious reason this would not work?
>
> I had documented this when I wrote the patch:
>
> http://sourceware.org/glibc/wiki/Destructor%20support%20for%20thread_local%20variables
Ah yes, the dlclose issue. I always forget about these because musl's
solution to all these problems is that dlclose is a no-op. :-) Anyway,
in that case I think your solution is correct, and I don't mind
implementing the same C++ TLS dtor API on our side.
Rich