Lock mechanisms yes, but the will only be contested when the other thread is asking for the ValueTree, which I’m assuming doesn’t happen very often. Other than that, this solution is just about as heavy as maintaining the original ValueTree, with no more hidden allocation than a ValueTree normally takes. MessageManagerLock is another option, but the risk of deadlocking is high.
I built this after reading this line from the other thread:
I was thinking of how to maintain a cached version of a ValueTree so that it could be ready by another thread, and came up with this solution. Happy to be proven wrong if I’ve misunderstood something though.