Re: The Hoard Scalable Memory Allocator

On Oct 22, 5:42 pm, "Chris Thomasson" <cris...@xxxxxxxxxxx> wrote:
<rani_shar...@xxxxxxxxxxx> wrote in message

news:1193092634.980718.199310@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

On Oct 22, 3:06 pm, "Chris Thomasson" <cris...@xxxxxxxxxxx> wrote:
<rani_shar...@xxxxxxxxxxx> wrote in message

[...]
I think that you are missing the point. The user of the DLL is not
aware about implementation details like per-thread heap when he simply
wants to unload the DLL. Now because the DLL is internally using per-
thread heap it can't be unloaded since it's bound to the lifetime of
the active threads. Assuming that one of these threads is the main
thread and therefore the DLL can't be unloaded before process
termination. Without the per-thread heap it's possible to unload the
DLL at any given time so your implementation is restrictive in that
sense. Since you are promoting a general purpose memory manager you
should think on how to preserve such important usability (i.e. provide
proper memory manager destruction).

Hoard has the same exact issues, and it is a general purpose memory manager.
Have you seen how they do it?

Maybe the Hoard memory manager is restricted to have the lifetime of
the process and its intended to be used has process wide allocator.
That's similar to MS processes heap (GetProcessHeap) without the
ability to create private heaps.
OTOH, I do believe that it's not very difficult to provide TSD without
such restriction.

With proper TSD API you should be able to destruct the memory manager
upon DLL unload (e.g. foo_shutdown).

You cannot destroy a heap if it is being referenced by something.

Unloading the DLL while there are still pending allocations from its
memory manager his a caller pre-condition violation (i.e. leaks).
There is no way to refer or release to such memory since the memory
manager is gone. This is basic lifetime management.
You can safely assume that there are no pending allocations on DLL
unload (in debug builds you can assert no leaks).

Rani

.

Relevant Pages

  • Re: The Hoard Scalable Memory Allocator
    ... The user of the DLL is not ... > aware about implementation details like per-thread heap when he simply ... Without the per-thread heap it's possible to unload the ... Since you are promoting a general purpose memory manager you ...
    (comp.programming.threads)
  • Re: The Hoard Scalable Memory Allocator
    ... The user of the DLL is not ... > aware about implementation details like per-thread heap when he simply ... Without the per-thread heap it's possible to unload the ...
    (comp.programming.threads)
  • Re: The Hoard Scalable Memory Allocator
    ... Now because the DLL is internally using per- ... Without the per-thread heap it's possible to unload the ... Since you are promoting a general purpose memory manager you ...
    (comp.programming.threads)
  • Re: heap shared with DLL
    ... In any case, in WinNT/2K/XP and in WinCE heaps are process-owned, and the heap manger (not the EXE or DLL) maintains alloc/free states of blocks. ... In MS desktop CRT, it creates a heap internally for malloc/free - and maybe still another for new/delete, so mixing is going to be a problem. ...
    (microsoft.public.windowsce.embedded)
  • Re: DLL pass vector by value crash
    ... I can't see why the issue of common heap and allocator (operator ... Presuming that you build your exe and dll with same compiler and same ... allocation functions are called, ...
    (microsoft.public.vc.mfc)