Do we need a blocking message queue on overflow in VST wrapper?

[p0nce]

Currently lock-free, but maybe it should block instead of crashing when overflowing.

[p0nce]

Possibly at least 3 thread: audio thread, parameter threads, UI threads .

[p0nce]

Remaining problems:

• size of lock-free queue?
• when overflowing the message queue, no locking but crashing instead

[p0nce]

tryLock should be used, since the GC could possibly halt all threads, even the thread pushing on the FIFO while the spinlock is taken. That is a risk.

[p0nce]

Since mutexes and semaphore are lock-free in the uncontended case, I don't think it would be so bad to use a locked queue instead. gfm.core queues can continue to use GC memory since UI threads (producers) are GC-enabled.

[p0nce]

There is currently a strange crash when multiple instancess, Mago says an exception is thrown but seems a bit random.

[p0nce]

Blocking message queue available with a version. The annoying thing is that the sync primitives might throw and that makes the mutexes and semaphore functions non-@nogc.