[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <87r18wdbwb.fsf@keithp.com>
Date: Mon, 24 Jan 2022 14:09:08 -0800
From: Keith Packard <keithp@...thp.com>
To: Florian Weimer <fweimer@...hat.com>
Cc: Sebastian Huber <sebastian.huber@...edded-brains.de>,
libc-coord@...ts.openwall.com
Subject: Re: Constructors/destructors for thread-local objects?
Florian Weimer <fweimer@...hat.com> writes:
> Yes, that's what I concluded as well.
> Why? They wouldn't be different from destructors registred using
> pthread_key_create.
I could have been more clear -- I meant in the context of
dlclose. Regular thread termination is easy enough.
> Dealing with dlclose is another matter, of course. We could say that
> once the classic ELF destructor for an object has started executing, the
> new TLS destructors will no longer run for this object. That should
> cover most memory deallocation needs. The classic ELF destructor would
> need an application-specific way to enumerate allocated per-thread
> resources.
That sounds reasonable; we'd limit the use of these thread-specific
destructors to thread termination and use the classing elf destructor
for dlclose, leaving the application (or, in this case, the DLL)
responsible for figuring out how to clean up all of its per-thread state
in the relevant destructor.
So, it looks like destructors could be useful and should be do-able, but
constructors have significant issues with dlopen, so we might want to
skip them entirely and let applications open-code initializers. That
also helpfully avoids figuring out how to handle allocation failures in
the initializers.
--
-keith
Download attachment "signature.asc" of type "application/pgp-signature" (833 bytes)
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.
