samedi 7 septembre 2019

Does set_new_handler store new_handler in thread local storage?

It has been asked whether set_new_handler is safe in a multi-threaded environment. I would like to know if C++11 and later implementations of the C++ standard library use the thread_local feature to store the std::new_handler. If implementations do not use thread_local, why not? That would seem to make the feature a bit more robust in multi-threaded environments.

I also don't really see how set_new_handler would work for a class that overloads new and sets a std::new_handler and creates (and owns reference to) an object that also overloads new and sets its own std::new_handler. I would expect that would be especially egregious if the owning class has options to reap/free memory, while the owned object decides to call abort/terminate.

I expect the usual advice is to use *nothrow *version of new and forget set_new_handler. If that is a universal opinion, why isn't set_new_handler a deprecated feature in the standard library?

Aucun commentaire:

Enregistrer un commentaire