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.
