Closed jrfondren closed 3 months ago
Yeah, I don't remember why I needed a {.threadvar.}
. Well, this is meant to be used from the main thread, and there are other threadvars in the code, and I don't have time or inclination to figure this out in the foreseeable future.
So please just fork it and use it like that.
The problem isn't that this is a threadvar, but that it's a threadvar that's initialized by toplevel code that only runs once, leaving the threadvar with only default initialization in other threads. You don't have any other threadvars like this.
You likely don't remember why you needed {.threadvar.}
because those were added by earlier PRs, #19 and #29.
Indeed, I don't remember because it wasn't me, apparently 😄 My intention was to keep illwill simple, so yeah, no thread safety, just use it from the main thread.
But your PR doesn't seem to cause any harm, so merging, after all 😄 Thanks!
Bumped version to v0.4.1 @jrfondren
... from a threadvar that's only initialized on the main thread, leading to zero-length toUTF8String results, and IndexDefect on
.runeAt(0)
That error can be seen by taking the examples/keycodes.nim and running it in another thread:
My use-case is making a TUI that's controlled by Erlang, and implemented by a Nim DLL. Since the limited NIF interface is used, the Nim DLL can't maintain a UI loop except in a separate thread.