Now that the --newruntime is starting to stabilize, I really wanted to try it with --threads:on as one of the worst problems with threading is not being able to pass closures (which contain a hidden ref to the captured bindings) across threads. I had high hopes that the newruntime would fix that as I understand that the hidden ref then becomes an owned ref which should be able to be passed, although perhaps not yet until the threads channels and threadpoos modules get refactored to match.
We can't even try it yet because of an error in the new runtime: "[FATAL] unpaired dealloc" even for a "Hello World" program that doesn't actually use any threading features!
It seems to me that one of the main reasons for the new runtime is that it will allow standard data structures such as ref object's, seq's, string's, anything containing a ref, and closures (which contain a hidden ref) to be more easily used across threads such as by spawn and may make channels more consistent to use anywhere. It may also mean that there need to be many less deepCopy's used across threads when ownership is clearly transferred.
Any ideas on why this is an when it might get fixed?
@mratsim, you had already reported the issue as at the following: https://github.com/nim-lang/Nim/issues/11844.
@Araq just (hopefully ;-) ) fixed the issue with https://github.com/nim-lang/Nim/commit/7024bb800ccf2c3e075c5dd605b8384a399ffe53, which turned out to be very simple as just discard'ing the returned value from an atomicDec.
Thank you very much, @Araq, for this timely response. Now just have to compile the DEVEL branch or wait for the next release to check it out.
@Araq: Fixed, not...
Your commit (https://github.com/nim-lang/Nim/commit/7024bb800ccf2c3e075c5dd605b8384a399ffe53) on file "lib/core/runtime_v2.nim" doesn't seem to have gone far enough, as I see three other places at lines 56, 62, and 68, where you use atomicInc/atomicDec without using discard, having only fixed the one at line 87.
But that isn't the source of the error anyway, as the message says, the error comes about because the allocs is less than or equal to zero when it is expected to be at least one. It seems allocations aren't balancing out with deallocations with threading on, perhaps because some file isn't seeing that hasThreadSupport is enabled and another file seeing it?