Safely extend the size of a malloced memory block after realloc

welkam via Digitalmars-d digitalmars-d at puremagic.com
Mon Aug 17 13:33:43 PDT 2015


On Monday, 17 August 2015 at 20:07:08 UTC, Steven Schveighoffer 
wrote:
> On 8/17/15 3:57 PM, welkam wrote:
>> // if the GC kicks in here we're f*****
>>
>> Why?
>>
>> static nothrow @nogc void removeRange(in void* p);
>> Removes the memory range starting at p from an internal list 
>> of ranges
>> to be scanned during a collection. <...>
>
> Because presumably the reason why you have added the range is 
> because it's not GC memory (as in this case). This means that 
> if a GC run kicks in right then, that range of data will not be 
> scanned, and the GC memory it may have been pointing at could 
> potentially be freed.
>
> -Steve

I might be wrong, but he should worry about GC before he removes 
that memory range from GC managed list not after. And his code 
smells to me. He gives full memory control to GC, but then wants 
to take it away, fiddle and give it back. I would allocate more 
than I need to so avoiding a need to extend the memory. If not 
then either allocate new chunk of memory, copy data and forget 
about old one or have a data structure where I could add new 
chunks of memory.
Its best to minimise system calls such as malloc and similar 
because they hit OS and slow down execution.


More information about the Digitalmars-d mailing list