On May 26 2022, "Richard W.M. Jones" <rjo...@redhat.com> wrote: > Is there any way to do this without the literal sleeps? Gitlab CI in > particular appears to be very contended (I guess it runs in parallel > on huge systems with vast numbers of unrelated containers). I've seen > threads being created that are so starved they never run at all even > in tests running for many tens of seconds. > > I'm thinking some kind of custom plugin which orders operations using > its own clock that it is incremented as certain requests arrive, but I > don't have a fully-formed idea of how it would work.
I think this should be possible. I've written similar tests for S3QL. However, it is much more complex and prone to result in deadlocks in cases where the tests should fail. Is there a timeout mechanism that is applied to individual tests? One way to do it is to have the test code and NBD server in the same process, so we can use mutexes etc to ensure that we are testing the intended sequence of events. Another way would be to have the test communicate with the NBD server through a side-channel (say a pipe), so that the test knows when to send the second request. Best, -Nikolaus -- GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« _______________________________________________ Libguestfs mailing list Libguestfs@redhat.com https://listman.redhat.com/mailman/listinfo/libguestfs