So, it seems that you're calling RNL broadcast message calls from a different thread than the actual RNL thread, but that is wrong, you do to need all call in the same actual RNL thread, but if you set the Server.Inteerruptable to true, then you can interrupt the RNL event wait timeout in the actual RNL thread from a another thread with Server.Interrupt. so that the actual RNL thread can process for example your own threadsafe message queue without any delay, but the more recommending is not to use the interrupt feature (because Windows, Linux and Android are no realtime operating systems, so there can be always latency-jitter in their thread context switch processes, which can be up to multiple 10ms in extreme really-full-CPU-load cases) and instead to set the event waitout lower from 1000ms to 10ms, 1ms or even with 0ms, if you will mixing the RNL thread and rendering main loop thread into one single thread, so that for example the Monitor VSync or something other in your graphics rendering process would overtake then this save-CPU-load-waiting.

Summary: RNL is single-threaded, so you should use a RNL instance always only in the same thread, either together with your own threadsafe message queues (for example based on my PasMP project), or merge more stuff into the same thread.

See my changes at

https://vserver.rosseaux.net/stuff/rnl_debug_pgd0.zip in your code

and my video at