Hi Phil,   can you ellaborate on the reliability issues of RtlAllocateHeap()? Are you talking about out-of-memory conditions or heap corruption with HEAP_NO_SERIALIZE in multi-threading scenarios or about performance in those cases? Are there reliability issues even without HEAP_NO_SERIALZE? Then RtlAllocateHeap() violates the Windows API specification.   Or you want C++ to provide facilities to provide ways to avoid/replace RtlAllocateHeap() for reliability or compliance reasons for the whole application, even for static and dynamic libraries, which have been directly linked to it? If C++ would provide a set_new_handle() function for connecting to an allocation routine in an application-wide way, what would prevent the static or dynamic library to call set_new_handle and link to RtlAllocateHeap? To really enforce it one would have to introduce ways into C++ to have translation units with higher privilege level that may call certain functions from the standard library (set_new_handler), other translation units may not. Also one would have to prevent the other translation units from being compiled with different settings or different standard library versions and prevent them from calling the Windows API directly? And you want to specifically prevent ntdll.dll from being compiled on this higher translation unit privilege level?   I think alternative approaches would be either:  - Have RtlAllocateHeap() give better (?) guarantees in heavily multi-threaded environments.  - Ask Microsoft to provide facilities to customize RtlAllocateHeap() behavior (e.g. for registering custom allocation routines) If the set_new_handler is extended, then one would have to  - Define a standard for nice behaving dynamic and static libraries that should neither call certain Windows API functions (like RtlAllocateHeap() or the new set_new_handler) directly nor depend on another library calling those API functions Best, Sebastian   -----Ursprüngliche Nachricht----- Von:Phil Bouchard via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Sa 11.02.2023 23:05 Betreff:[std-proposals] set_new_handler extension An:Std-Proposals_at_[hidden]; CC:Phil Bouchard <boost_at_[hidden]>; Greetings, From my experience the underlying Windows RtlAllocateHeap() and RtlFreeHeap() aren't reliable in extensive multithreading usages. One solution is to use thread-local memory pools, which are not only faster but safer. Regarding the C++ standards there is only the following function that can be use upon memory allocation failures: https://en.cppreference.com/w/cpp/memory/new/set_new_handler Why can't we have a handler that would be called before it even tries to allocate anything? This way we could implement our thread-local allocation routines through the C++ standards and not relying on some linker hacks magic. Regards, -- Email Signature Logo <https://www.fornux.com/> *Phil Bouchard* facebook icon <https://www.linkedin.com/in/phil-bouchard-5723a910/> CTO T: (819) 328-4743 E: phil_at_[hidden]| www.fornux.com <http://www.fornux.com> 8 rue de la Baie| Gatineau (Qc), J8T 3H3 Canada Banner <https://goglobalawards.org/> Le message ci-dessus, ainsi que les documents l'accompagnant, sont destinés uniquement aux personnes identifiées et peuvent contenir des informations privilégiées, confidentielles ou ne pouvant être divulguées. Si vous avez reçu ce message par erreur, veuillez le détruire. This communication (and/or the attachments) is intended for named recipients only and may contain privileged or confidential information which is not to be disclosed. If you received this communication by mistake please destroy all copies. -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals