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.