[Issue 15484] core.memory.GC.disable() is not @nogc

[d-bugmail--- via Digitalmars-d-bugs]

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

Iain Buclaw  changed:

   What|Removed |Added

   Priority|P1  |P4

--

[Issue 15484] core.memory.GC.disable() is not @nogc

[via Digitalmars-d-bugs]

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

Steven Schveighoffer  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||schvei...@yahoo.com
 Resolution|WONTFIX |---
   Severity|normal  |enhancement

--- Comment #4 from Steven Schveighoffer  ---
@nogc means no allocations, no more no less. See Walter here:
https://forum.dlang.org/post/ogal82$2ubk$1...@digitalmars.com

I can see a use case for this, but not with the OP's code, since it has
allocations (and obviously those aren't @nogc).

But if you were in, let's say a critical part of a rendering loop, and did not
want to drop frames, you may disable the gc to prevent *other threads* from
collecting during this critical period, and then turn it back on.

So I think the enhancement request is legitimate.

--

[Issue 15484] core.memory.GC.disable() is not @nogc

[via Digitalmars-d-bugs]

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

Rainer Schuetze  changed:

   What|Removed |Added

 CC||r.sagita...@gmx.de

--- Comment #3 from Rainer Schuetze  ---
>  Because @nogc isn't supposed to mean "a GC collection cycle will not be 
> triggered", but rather "no GC code is accessed at all" (which also refers to 
> GC.enable/disable).

My impression is that everybody has a different notion of what @nogc means.
Contrary to your assumption, GC.addRoot and GC.addRange have been marked @nogc.
The spec only says "@nogc applies to functions, and means that that function
does not allocate memory on the GC heap" which still disallows foo() to be
@nogc.

--

[Issue 15484] core.memory.GC.disable() is not @nogc

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #2 from Vladimir Panteleev  ---
(In reply to Daniel from comment #1)
> Imagine an environment where you cannot even link with the GC, not because
> of performance reasons but in order to reduce the size of your binary.

Sounds like a good argument.

I think it's better to be conservative, because it's easily possible to go the
other way around in case of specific corner cases by creating a wrapper
function that casts to @nogc.

I'll close this (as the issue is over a year old), but feel free to reopen if
you have a compelling argument to do so.

(In reply to Infiltrator from comment #0)
>// do something including allocations

Not sure what you mean by this exactly; did you mean that the compiler would
detect the GC.disable call and allow using "new" in-between GC.disable /
GC.enable invocations, despite the @nogc attribute on the code? Because @nogc
isn't supposed to mean "a GC collection cycle will not be triggered", but
rather "no GC code is accessed at all" (which also refers to
GC.enable/disable).

--

[Issue 15484] core.memory.GC.disable() is not @nogc

[via Digitalmars-d-bugs]

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

Daniel  changed:

   What|Removed |Added

 CC||wyr...@gmx.net

--- Comment #1 from Daniel  ---
Imagine an environment where you cannot even link with the GC, not because of
performance reasons but in order to reduce the size of your binary.

For this reason, no single function/symbol which is part of the GC should be
allowed in @nogc code, regardless if it allocates or not.

--