@woggioni The GC is involved in your example because the `proc(): auto = pt` is
a closure; it captures `pt` as part of its environment.
Closures in Nim are bound to the thread that creates them because the closure's
environment is allocated on the thread-local heap (managed by the thread's GC).
@mashingan this confirms that even local value-typed variables are GC managed..
But using ref doesn't solve the problem:
type
P2d = object
x, y: float
P2dp = proc(): ref P2d
var thef: P2dp = nil
proc foo(): auto =
var pt :
@woggioni, how about adding threading to your example, like
# compile with --threads:on --threadAnalysis:off
# because this thread need to modify `thef` value
type
P2d = object
x, y: float
P2dp = proc(): P2d
var thef: P2dp = nil
> @mikra "After the fact", it totally makes sense to me that I would need to
> keep a reference to a thread. But as I was writing the code, it wasn't
> obvious at all, because I'm used to Java, where threads are "allocated on the
> heap", and so they don't get destroyed by leaving the scope wher
@monster certainly the code should crash with a better error message. Please
report this on GitHub.
@monster yea threading could be painful :->. my 2cts: if you go for threads and
you have strange spurious side effects/crashes the likelihood turns almost to 1
that it has to do with threading.
I don't know how this could be handled. Maybe the compiler could check that
some references going out
@mikra "After the fact", it totally makes sense to me that I would need to keep
a reference to a thread. But as I was writing the code, it wasn't obvious at
all, because I'm used to Java, where threads are "allocated on the heap", and
so they don't get destroyed by leaving the scope where they w
@monster please take a look into nim's thread implementation. The nim-type
"Thread" contains the systems thread handle and so on. So I think it's a good
habit to keep this reference vital You need it also later on for cleanup. Hope
this helps you.
OK, I've got it! It has _nothing_ to do with runForever() or asyncdispatch.
Here another example that crashes:
import os
proc whatever() {.thread, nimcall.} =
echo("TEST")
proc initProcessX(): void =
echo("In initProcess()")
var thread: Thread[void
BTW on my machine (archlinux 64bit) it breaks in this way
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
In doStuff()
In initProcess()
[New Thread 0x770aa700 (LWP 992)]
Thread 2 "test" received
@monster As far as I can remeber GDB cannot read Visual C debug symbols, you
have to use the Visaul Studio debugger for that to work
I've found where gdb is (it wasn't in the path yet), and tried your
instructions (I have never used gdb...). That is what I got:
C:\Code\geth\src>gdb runforever.exe
GNU gdb (GDB) 7.11.1
...
Reading symbols from runforever.exe...(no debugging symbols found)...done.
(gd
You can try running your exe using gdb: `gdb runforever.exe`. Then type `run`
in gdb and once it crashes `bt`.
Unfortunately, no. All I get is what I wrote under "Result:" in the original
post. I'll try changing compiler parameters, to see if I can get more info.
This likely has little to do with that error. Do you have any stack traces of
where the crash happens? I don't have a windows machine to test this on :
Hmm. I added echo(".") in "doNothing()", to be sure it's not "optimized away",
but it still crashes. Shouldn't "doNothing()" im my edited example count as a
"pending operation"?
Also, in my real code, when the error first appeared, I have something like
this:
proc initCluster(port
>From the manual of poll(): Waits for completion events and processes them.
>Raises ValueError if there are no pending operations. The implementation
>raises the error if:
if p.handles.len == 0 and p.timers.len == 0 and p.callbacks.len == 0:
Your example runs fine if you protect the poll call s
Interesting! Does anyone know what "No handles or timers registered in
dispatcher" actually mean? That is, why is it an error?
Regarding the compiler, I hadn't thought about trying different compilers to
work around crashes. But unfortunately, I want to use this in UE4, and UE4
pretty much requ
I tested using GCC 7.2 msys2 on Windows 10. Nim 0.17.2
When compiled with no release, it simply crashed/segfault.
When compiled with release, it gave: Error: unhandled exception: No handles or
timers registered in dispatcher. [ValueError]
I wonder if it is a compiler issue. My understanding is that the vc compiler
isn't as up to date as gcc and clang, especially for C. It might be worth
trying a different compiler.
Windows 10, x64
Microsoft Windows [Version 10.0.16299.192]
(c) 2017 Microsoft Corporation. All rights reserved.
C:\Users\Sebastien Diot>nim --version
Nim Compiler Version 0.17.2 (2017-09-07) [Windows: amd64]
Copyright (c) 2006-2017 by Andreas Rumpf
git ha
Thanks for reproducing. It doesn't crash for me (macOS), what OS are you on and
what Nim version are you using?
btw, the `: void` is redundant for proc return types.
I think I can. I'm not sure if it is the same problem as in my main module, but
this crashes for me:
import asyncdispatch
import os
proc runForeverThread() {.thread.} =
## Executes runForever() in a separate thread.
runForever()
proc initProcess
Can you reproduce the crashes in a simple program that creates a new thread
that calls `runForever` (and does nothing else except waiting for that thread)?
@Hlaaftana Thanks. That was rather "obscure"; I wouldn't have thought there
were two versions of createThread(). Unfortunately, I changed the code as you
suggested, and it does not make the crash go away.
I think there is a single example of calling runForever() in the documentation.
It is just
Adding [void] to createThread makes it call [this
proc](https://nim-lang.org/docs/threads.html#createThread,Thread\[TArg\],proc\(TArg\),TArg),
which needs an argument to supply to the proc. However, you should be calling
[this
one](https://nim-lang.org/docs/threads.html#createThread,Thread\[voi
In a previous post today, I mentionned I got "unexplanable" crashes, that were
not always reproducible. It turn out, the crashes seem to be caused by
runForever().
I have async code in a single module, the same one where I call runForever().
If I comment out the code calling runForever(), the c
27 matches
Mail list logo
