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: Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>
- To: Rich Felker <dalias at aerifal dot cx>
- Cc: Siddhesh Poyarekar <siddhesh at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 1 Aug 2013 10:48:08 +0530
- 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>
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.
> 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.
Siddhesh
--
http://siddhesh.in