Comment #0 by lt.infiltrator — 2015-12-31T07:03:43Z
I don't know whether this is valid, but core.memory.GC.disable() is not @nogc.
Should the following code be classified as able to hold a @nogc tag and be able to be called by @nogc functions?
auto foo() {
core.memory.GC.disable();
// do something including allocations
core.memory.GC.enable();
return something;
}
Comment #1 by wyrlon — 2015-12-31T11:05:57Z
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.
Comment #2 by dlang-bugzilla — 2017-07-21T07:52:47Z
(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).
Comment #3 by r.sagitario — 2017-07-21T15:55:22Z
> 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.
Comment #4 by schveiguy — 2017-07-21T16:31:15Z
@nogc means no allocations, no more no less. See Walter here: https://forum.dlang.org/post/[email protected]
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.
Comment #5 by robert.schadek — 2024-12-07T13:36:06Z