[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d4c83f41-4c44-63fc-e40f-3075020974e8@embedded-brains.de>
Date: Mon, 24 Jan 2022 08:19:22 +0100
From: Sebastian Huber <sebastian.huber@...edded-brains.de>
To: Florian Weimer <fweimer@...hat.com>
Cc: libc-coord@...ts.openwall.com
Subject: Re: Constructors/destructors for thread-local objects?
On 23/01/2022 21:37, Florian Weimer wrote:
> * Sebastian Huber:
>
>> I would like to add something similar to the .init_array and
>> .fini_array at least for Newlib. Would .tls_init_array and
>> .tls_fini_array good names?
>
> You need to allocate ELF section types and dynamic tags, too. This
> probably should make it to the ELF generic ABI. The names only matter
> for static linking (which is probably the case you are interested in).
Ok, is this done by starting a thread in this group
https://groups.google.com/g/generic-abi
?
>
>> extern void (*__tls_init_array_start []) (void);
>> extern void (*__tls_init_array_end []) (void);
>>
>> extern void (*__tls_fini_array_start []) (void);
>> extern void (*__tls_fini_array_end []) (void);
>>
>> Do we need .tls_preinit_array?
>
> I thought a bit about this, and the semantics of per-thread initializers
> are really fuzzy when it comes to dlopen: What do you do for the
> existing other threads in that case? I really do not see there is a
> clean way to support per-thread initializers in the presence of dlopen.
I have to admit that I didn't thought about dlopen(). You have to clear
.tbss and initialize .tdata for existing threads, so there must be some
way to get access to all existing threads. Wouldn't it be possible to
run the thread-local constructors in a signal handler?
>
> Destructors do not have this issue.
>
>> It is unlikely that another C library will use this, but anyway, I
>> would like to use some names which could be used elsewhere as well.
>
> I'm interested in this for glibc as well (well, the destructor part).
> __cxa_thread_atexit has to allocate, but has no way to report allocation
> failure, so it just crashes the process. Registration for global
> destructors has the same problem, but presumably dlopen is a bit rarer
> than thread creation.
Yes, the resource allocation issue with __cxa_thread_atexit() was one of
the reasons that let me think about the new sections. I would like to
support applications which do not dynamically allocate memory at all.
>
> The destructors should probably take an iteration count as argument, and
> a return value that's non-zero if any action was taken by the
> destructor. I think this is needed because it is not always possible to
> destruct per-thread resources in a single pass. For example, a logger
> handle could be brought back to life if another destructor needs to log
> something. The C library would keep running all destructors until all
> of them signal that no work was left to do anymore.
This sound similar to the POSIX key destructors where up to
PTHREAD_DESTRUCTOR_ITERATIONS destructor call iterations are done.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber@...edded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
