https://issues.dlang.org/show_bug.cgi?id=14934

Martin Nowak <code@dawg.eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |code@dawg.eu
         Resolution|---                         |WORKSFORME

--- Comment #1 from Martin Nowak <code@dawg.eu> ---
And don't even think about what happens when a collection is triggered while realloc copies the data from the old array to the new array.

> updateFunc would be called within the GC lock, preventing any of the issues described above.

Please let's try to avoid arbitrary code execution with the GC lock held.

> This would work if GC.disable would actually guarantee that the GC never runs.

This is what http://dlang.org/phobos/core_thread.html#.thread_enterCriticalRegion and http://dlang.org/phobos/core_thread.html#.thread_exitCriticalRegion are for, using them should readily solve your problem.

void* reallocImpl(void* p, size_t newSize)
{
  thread_enterCriticalRegion();
  auto oldp = p;
  p = realloc(p, newSize);
  if (p !is oldp)
  {
      GC.removeRange(oldp);
      GC.addRange(p, newSize);
  }
  thread_exitCriticalRegion();
  return newPtr;
}

--

https://issues.dlang.org/show_bug.cgi?id=14934

--- Comment #2 from Martin Nowak <code@dawg.eu> ---
Maybe there could be a dead-lock in acquiring the GC lock in a critical region. Need to recheck that.

--

https://issues.dlang.org/show_bug.cgi?id=14934

Steven Schveighoffer <schveiguy@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |schveiguy@yahoo.com
         Resolution|WORKSFORME                  |---

--- Comment #3 from Steven Schveighoffer <schveiguy@yahoo.com> ---
(In reply to Martin Nowak from comment #1)
> Please let's try to avoid arbitrary code execution with the GC lock held.

I really don't see another way to do this. Your idea of using enterCriticalRegion isn't viable, because you need to call removeRange and addRange (which take the lock, that might be held while attempting to suspend the threads). Unless I misunderstand how it works.

However, I don't think it needs to be an "advertised" feature. I'm not sure we need to do it via a delegate, all we need is exposure to the lock. This needs to be done only in low-level situations.

> void* reallocImpl(void* p, size_t newSize)
> {
>   thread_enterCriticalRegion();
>   auto oldp = p;
>   p = realloc(p, newSize);
>   if (p !is oldp)
>   {
>       GC.removeRange(oldp);
>       GC.addRange(p, newSize);
>   }
>   thread_exitCriticalRegion();
>   return newPtr;
> }

Note, you need to remove and re-add the range in both cases, because the new range is bigger.

--

https://issues.dlang.org/show_bug.cgi?id=14934

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P3

--

https://issues.dlang.org/show_bug.cgi?id=14934

--- Comment #4 from dlangBugzillaToGithub <robert.schadek@posteo.de> ---
THIS ISSUE HAS BEEN MOVED TO GITHUB

https://github.com/dlang/dmd/issues/17309

DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB

--