Hey! I just read this paragraph in the README:
Problem on some callbacks
example for set-audio-stream-callback:
the following happens:
MoarVM panic: native callback ran on thread (some-thread-id) unknown to MoarVM
Solution yet to be found.
help is appreciated!
I've stumbled over this myself in the past. The cause is that the outside C code (raylib in this case) spawns a new thread and then calls into MoarVM with that thread. MoarVM has a management datastructure associated with every thread it knows about. It detects that this thread is unknown and then throws that error.
There is a work around and a clean solution.
Workaround
Implement a mechanism on the C side to move the call over to a thread that MoarVM knows about. That works by having a MoarVM spawned thread wait on a mutex. In the raylib callback you save the data you need to pass to some variable and then signal that mutex. The MoarVM known thread then picks up that data and uses it.
Clean solution
This issue can be fixed once and for all by teaching MoarVM to not die when an unknown thread is seen, but instead set up the management datastructure for it and then happily proceed. This is simply Not Yet Implemented. Jnthn, the MoarVM architect has confirmed that this the way to do it and it shouldn't be terribly difficult to do. (For some value of terrible.)
Hey! I just read this paragraph in the README:
I've stumbled over this myself in the past. The cause is that the outside C code (raylib in this case) spawns a new thread and then calls into MoarVM with that thread. MoarVM has a management datastructure associated with every thread it knows about. It detects that this thread is unknown and then throws that error.
There is a work around and a clean solution.
Workaround
Implement a mechanism on the C side to move the call over to a thread that MoarVM knows about. That works by having a MoarVM spawned thread wait on a mutex. In the raylib callback you save the data you need to pass to some variable and then signal that mutex. The MoarVM known thread then picks up that data and uses it.
Clean solution
This issue can be fixed once and for all by teaching MoarVM to not die when an unknown thread is seen, but instead set up the management datastructure for it and then happily proceed. This is simply Not Yet Implemented. Jnthn, the MoarVM architect has confirmed that this the way to do it and it shouldn't be terribly difficult to do. (For some value of terrible.)