Date: Sat, 11 Feb 2023 17:05:24 -0500
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,
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.
Received on 2023-02-11 22:05:26