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