I'm Curious About the Global Blocking Mutex for Reusable Containers

[kalverra]

I noticed this global mutex that is flipped on when Reuse: true, and am curious as to why, specifically when the container is "in a parallel execution, via ParallelContainers or t.Parallel()".

I ask as we are working on an extensive test suite running with t.Parallel(), each test launching a decent amount of testcontainers. We had Reuse: true to help us with some of our retry logic, but found that testcontainers was limiting how many containers could launch at once when running multiple tests in parallel, seemingly arbitrarily, even when there was plenty of RAM and CPU available. After setting Reuse: false, we no longer have that issue and take full advantage of available resources. I'm wondering:

1. Is this intentional to stop to world and prevent parallel execution when Reuse: true? Why?
2. Since this spawned from us looking at our retry logic (if the container fails to launch, change some params and try again), I'm wondering if there is a more testcontainers-y way to accomplish this than our current style of setting Reuse: true and fiddling with the container request before relaunching it.

[mdelapenya]

Hi @kalverra I'm trying to get more context of this. In the meantime, that code was added here: #593. Could you take a look 🙏 ?

[kalverra]

Thanks, this answers question #1 for me. Bummer that there's a race that causes this behavior.

[mdelapenya]

Could you expand more on your use case? I can imagine you want to "reuse" the container for performance issues, right? I have to say that our reuse mode is not robust and we have something in mind to replace it (not landed an impl yet).