We only used the samplesMutex lock in places where trackedSamples list was accessed. But in Sample::OnProcessed, we also access the TexturePool from a different thread. This lead to occasional crashes, because the TexturePool is not inherently threadsafe. So I extended the locks to also cover all TexturePool access.
We only used the samplesMutex lock in places where trackedSamples list was accessed. But in Sample::OnProcessed, we also access the TexturePool from a different thread. This lead to occasional crashes, because the TexturePool is not inherently threadsafe. So I extended the locks to also cover all TexturePool access.
This should fix the crash seen in #320.