I really don’t know about this I’m afraid. It seems to be something specific to the Elk OS and I don’t have a copy to try and am a bit slammed with other stuff to investigate why this isn’t working at the moment.
With the Elk OS are you able to run a stand-alone version of your plugin, outside of Sushi? Does that work as expected?
Or are you able to construct a small example using a lock on a non-audio thread that exhibits this behaviour? It could be a bug in the Elk OS?
Thanks for your answer. I guess the problem has to do with file locks because of the audio thread running in an RT kernel and the message thread running in the “normal” linux kernel. I’ll do more research, but I think I’m lacking basic understanding of how file locks work. So maybe to rephrase my previous question: if I see in tracktion engine that a file is locked, does it necessarily mean that my app locked it at some point in the past, or could it be an external process that locks the file?
With the Elk OS are you able to run a stand-alone version of your plugin, outside of Sushi? Does that work as expected?
Unfortunately not because then the audio drivers don’t work. I could program my own audio drivers for ELK/JUCE but well, I’d rather prefer not (thought in the long term might not be a bad solution).
Or are you able to construct a small example using a lock on a non-audio thread that exhibits this behaviour? It could be a bug in the Elk OS?
I have not really tried that, but I think this is because I still don’t have a basic understanding of how locks work so I should learn more first.
The only thing I can think of is to step through the LockedReaderFinder constructor and see how far it gets. The isLocked member is a bit misleading as it gets constructed as true and is really only used to ensure the juce::ReadWriteLock exitRead is called on destruction.
I’m guessing it will either be failing in tryEnterRead or findReaderFor but I’m not sure why.
