interesting this came up in another topic
I had a quick look at the code and I say it is not thread-safe…
first I should say, its common for threading bugs to lurk for really long periods of time, and not cause any issue - simply because they require certain pre-conditions to be triggered, and also often very ‘unfortunate’ timing.
also, there can be other things in play e.g. timing constraints that are in play that are unintentional.
sure std::map is ok for const access… but not for being modified.
I’ll just give one example… so the processing code has this in it.
void process(const ProcessArgs &args) override {
if(sourceExists(label)){
TeleportInModule *src = sources[label];
for(int i = 0; i < NUM_TELEPORT_INPUTS; i++) {
Input input = src->inputs[TeleportInModule::INPUT_1 + i];
theres a couple of issues I believe here:
first the divisibility of sourceExists (which is find) and then the access.
in a multi-threaded environment (esp with multi cores), there is nothing to stop the source existing for the IF statement (so true), but then for the source to disappear before sources[label] is executed.
even if this was ok, another thread (Id assume the UI thread) could delete the object that was refer to in the map whilst we have a local copy of the pointer . i.e. its not just the map that needs to be safe, but also the thing it contains.
I could go on… but you probably get the picture…
“But it doesn’t crash” - well lucky you 
there are quite a lot of pre-conditions at play here…
obviously, its only going to occur if you use these objects in your patch.
next. I think its most likely to occur with multi dsp threads (vcv standalone defaults to one, but in daw, we are likely be using more)
the other reason is the ‘danger time window’ is very small… if we look at above, we can see it quickly access the pointer, and just sets a few floats … this is going to be very few cpu cycles in which to get it wrong… also this is only an issue when the map changes, and in particular when the source is removed.
so it’s extremely unlikely that this would occur at the same time. (but importantly, not impossible)
also you’d need to look at the vcv rack ui code, it may be that it is some how protecting this module with additional timing constraints. e.g. if it suspended processing of all modules whilst it removed modules or something similar.
as I said, in multi threaded coding, it is not unusual to have code that can run for days/months and be perfectly happy… then one bad day, it just crashes out of the blue.
so you’ll almost certainly be fine… but id not want to risk it in a live performance, or have unsaved work, and Id be cautious in recommending it to others in multi threaded environment.