I wrote this code a couple days ago and tested it with the default gc, it worked as expected: https://hastebin.com/zojokonuwi.php if I compile with gc = arc or gc = orc, though, I get a segfault:
Got here
No stack traceback available
SIGSEGV: Illegal storage access. (Attempt to read from nil?)
Am I causing undefined behavior, or is this a bug with Arc? I tried to debug it with gdb, but when i run it in gdb, it runs fine. Weird...
If this is a bug in Arc, how do I work around it and is it already open on the issue tracker?
The behavior I want is equivalent to the C++ detatching of threads; I come from Rust, where this happens automatically, so I didn't have to worry about that; how do I do that in Nim? Ideally I just want the threads to be killed when the application terminates.
and why must the thread object be allocated on the heap?
why must the thread object be allocated on the heap?
Typically it must not. But particular implementations of wrappers for OS threads ( so called threads objects) may have some limitations ( usually it does for simplicity of usage or security reasons - just like for file object case) - common practice. if you want overall control and flexibility - use threads at OS system level. I wonder whether it is Nim's case
I missed this, thanks! It does still SIGSEGV though.
By changing the buffer to 512 as @planetis mentioned, it's running fine (?) when I tried it on Alpine Docker. I got below from the console and it's never quitting (and also eating the cpu because of while true: discard ), is this the expected behaviour?
we're in the parent 7
from child 0
Got here
sigchld
10, -1
@DIzer you're describing threadpool right?
@codic12 there is destroyThread but I guess it's not implemented? Perhaps you can finish it's implementation.