std.allocator needs your help

Rainer Schuetze r.sagitario at gmx.de
Tue Sep 24 11:28:46 PDT 2013



On 24.09.2013 10:46, Dmitry Olshansky wrote:
>
>> * expand(b, minDelta, maxDelta) grows b's length by at least minDelta
>> (and on a best-effort basis by at least maxDelta) and returns true, or
>> does nothing and returns false. In most allocators this should be @safe.
>> (One key insight is that expand() can be made @safe whereas shrink() or
>> realloc() are most often not; such mini-epiphanies are very exciting
>> because they put the design on a beam guide with few principles and many
>> consequences.) The precondition is that b is null or has been previously
>> returned by allocate(). This method is optional.
>
> Great to see this primitive. Classic malloc-ators are so lame...
> (+ WinAPI Heaps fits here)

expand is nice, but I don't like minDelta and maxDelta as arguments. On 
a shared allocator this can lead to undesired side-effects, i.e. when 
this function is called concurrently on the same block by two threads, 
the net result will be the sum of the deltas of the two threads, while 
later synchronization on the memory block might only allow one thread to 
actually use the extended memory area. This can happen with gc_extend in 
the current GC when appending to a shared array.

I'd prefer the function to actually pass the desired sizes:

void[] expand(void[] b, size_t minSize, size_t maxSize);


More information about the Digitalmars-d mailing list