smallfunction VS readerwriterqueue

However, std::function which can be used for storing multiple closures can indeed heap allocated. Since this is undesirable, I use an equivalent with static fixed storage instead: https://github.com/jcelerier/smallfunction/blob/master/smallfun/include/smallfun.hpp which gives me a compile error if I try to stuff too much data in there.

and conversely from the engine to the UI thread ; Qt signals do not cut it as emitting them allocate, if only a few bytes. (Doing it naively with std::function doesn't cut it either - I use this instead to store these functions: https://github.com/jcelerier/smallfunction/blob/master/small... ; also, the audio threads feeds back those functions into the main thread after their execution so that any memory owned by the lambda ends up being freed here and not in the audio thread.)

I have looked at the commonly recommended - https://github.com/cameron314/readerwriterqueue - https://github.com/rigtorp/MPMCQueue

The PREEMPT error looks like its a C module but I cannot tell from he little snippet of the log - you may do better to move the *arr and Synchthing into Docker containers to keep the OS cleaner.

For audio DSP in a Qt app I have good success with using a lock-free queue (e.g. https://github.com/cameron314/readerwriterqueue) to communicate from / to the UI threads. Code more-or-less looks like

    connect(model, &ModelObject::somethingChanged, [=] {

We recently removed readerwriterqueue from our project due to issues and replaced with simple locking queue (and got better performance in the result). Your code looks interesting, but we can't use it due to C++17 usage.