You can replace the global allocation functions to modify the behaviour of
them entirely (and not just change the failure behaviour). This should do
exactly what you want.

On Sat, Feb 11, 2023 at 17:05 Phil Bouchard via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> 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
> <https://www.google.com/maps/search/8+rue+de+la+Baie%7C+Gatineau+(Qc),+J8T+3H3+Canada?entry=gmail&source=g>
>
> 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
>