std.allocator needs your help

Dmitry Olshansky dmitry.olsh at gmail.com
Tue Sep 24 12:12:44 PDT 2013


24-Sep-2013 22:28, Rainer Schuetze пишет:

> 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);

+1


-- 
Dmitry Olshansky


More information about the Digitalmars-d mailing list