I’m working on a module that has several optional expanders that can provide additional inputs, outputs and controls to influence what the core module does. The expanders are only providing the extra controls, they don’t actually do any processing, that’s all done in the process()
method of the core module. Because there can be multiple expanders chained next to each other, and there can be multiple instances of some of them, I’m accessing the input and outputs of the expanders directly (so like the first code sample on Plugin API Guide - VCV Rack Manual, not using messages as described below it). I just keep checking the left/right expander until I encounter a module that can’t be used as an expander of my core module and once I have that list, I access the module->inputs
, module->outputs
and module->params
directly.
I was wondering however if that may cause issues if the Rack Engine is set to run on multiple threads: if one of the expander modules is removed while the process()
method of my core module is in progress, can it occur that the expander module was present at the start of my process
function, but has been removed (and deleted from memory) by the time I try to access its outputs later on in the function (causing memory corruption)? Or does the VCV Rack engine internally make sure that operations such as removing a module from a patch don’t occur while the process()
method of one of the modules is still ongoing?
No, since your expander modules don’t do anything in process()
.
Rack doesn’t let this happen. See the Engine
class for thread-safety documentation.
1 Like
Thanks for the quick reply! I suspected that Rack wouldn’t do the removal while a process is ongoing, but wanted to check to make sure.
fwiw I’ve made a lot of modules, and have always found VCV to be quite thread-safe. Of course you need to play by the rules, but for sure I have never seen the “rug get pulled out from under a module” when inserting or deleting.