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: Thu, 1 Aug 2013 01:25:44 -0400
- Subject: Re: Thread-local support for non-POD data objects
- References: <20130712172128 dot GC32671 at spoyarek dot pnq dot redhat dot com> <20130725010852 dot GA4284 at brightrain dot aerifal dot cx> <CAAHN_R3XPnHsUXgtrDZPWXMvcPGWtt6ZgNPtE_jznaXGtXAo8Q at mail dot gmail dot com> <20130801034935 dot GG221 at brightrain dot aerifal dot cx> <CAAHN_R3o6P0L7kmHCj5PBjj8_hh4bngx3P7jJJt7Y-FdxEs9wg at mail dot gmail dot com>
On Thu, Aug 01, 2013 at 10:48:08AM +0530, Siddhesh Poyarekar wrote:
> On 1 August 2013 09:19, Rich Felker <dalias@aerifal.cx> wrote:
> > Since this is a new feature, my feeling is we should try to get it
> > right. There should be some way for the dynamic linker to know the
> > maximum number of __cxa_thread_atexit calls the library will make so
> > it can reserve space for them. Fixing plain __cxa_atexit can be a
> > separate issue.
>
> The way it is currently implemented, any fix that happens for this
> could be done for both __cxa_atexit and __cxa_thread_atexit. The
> feature is already out with gcc-4.8, so major design changes may be
> difficult to make at this stage. Maybe you could talk to the gcc
> folks and see if this is possible.
I see.
> > How many calls to __cxa_atexit does the compiler generate? Offhand it
> > looks like it generates one per object, which is really ugly and
> > inefficient; there's no reason for it to be more than one per
> > translation unit, and it could really be just one per dso with some
> > toolchain help, or even better, none at all, using fini_array instead.
>
> It uses the init_array/fini_array currently for __cxa_atexit, but it
> is still one call per object I think.
What I meant is that I don't see why it even needs to call a function
to register the dtors. It should just be able to put the dtors in the
fini array, which will automatically be run on program termination (or
dlclose unloading).
Rich