GC.enable: raise if GC is not disabled

[asterite]

Fixes #4721

[oprypin]

Why not do the same for disable then?
https://github.com/ivmai/bdwgc/blob/347c1f0d0b2be5c811e7449ae2afa1b1e2d42fcc/misc.c#L1827

[asterite]

@oprypin There's no assertion there, as far as I can see. The idea is that you can invoke disable many times, and a counter is added, and then you need to invoke the same amount of enable to finally enable it. That's because you might want to do:

GC.disable
run_something
GC.enable

and run_something might end up also disabling and enabling the GC, and without a counter that's impossible to do.

[RX14]

We should already know we're in GC.enable from the stacktrace. We don't prefix with the method name in other parts of the stdlib at least.

[asterite]

The stack trace I get is:

GC is not disabled (Exception)
0x108ef5695: *CallStack::unwind:Array(Pointer(Void)) at ??
0x108ef5631: *CallStack#initialize:Array(Pointer(Void)) at ??
0x108ef5608: *CallStack::new:CallStack at ??
0x108ee4d55: *raise<Exception>:NoReturn at ??
0x108ee4d01: *raise<String>:NoReturn at ??
0x108f126ff: *GC::enable:Nil at ??
0x108ee47f4: __crystal_main at ??
0x108ef48c8: main at ??

Seems pretty cryptic to me. The call for GC::enable is like 6 lines below.

[oprypin]

It's a whole another issue, but it doesn't have to be this way.

[asterite]

What about "Can't enable GC: GC is not disabled". I mean, there's nothing wrong with being just a bit more verbose, right?

[lbguilherme]

I don't have an use case, but I think it is better to not raise any exception in this case and just return. GC.enable always finish with a enabled GC in the same way that file.close always finish with a closed file, even it it was already closed. This exception is not helpful as there was nothing really wrong happening.

[oprypin]

Have you read the issue? Calling GC.enable actually disables the garbage collector

[lbguilherme]

Yes. I would implement it this way:

  def self.enable
    unless LibGC.is_disabled != 0
      return
    end
    LibGC.enable
  end  

[asterite]

But if you call GC.enable without calling GC.disbale, it's a bug. Bugs shouldn't be silently ignored.

[lbguilherme]

Doesn't closing a file twice fall under the same category of bug? I'm not against either behavior, just wanting to be consistent.

[asterite]

@lbguilherme

GC.enable
puts "Hello"
GC.disable

What do you expect that do to?

To me, after the last line, the GC should be enabled. But in fact, it won't be like that, with your proposal.

Closing a file twice is fine, it's an idempotent operation. Enabling a GC that's not disabled can lead to the code above, and then finding where the problem of a disabled GC is becomes super tricky.

[sdogruyol]

LGTM?