09.03.2023 07:39, Thomas Munro wrote:
> Pushed, without that test.
>
> I realised that the test would not be stable in the build farm. If we
> made the lock timeout high, the test would be slow, but if we made it
> low, then there would be two possible outputs depending on a race, and
> 10ms as you had it seems -- I guess? -- likely to be unstable under
> valgrind or an RPi2 or something. There is probably some clever way
> to write a different test schedule, but the new code is exercised by
> existing tests, and the assertion has been failing once every couple
> of days on CI since I started collecting that data a few weeks ago, so
> we have some kind of coverage, at least for master.
I had thought that we can use the same timeout that can be seen in
a couple of other tests, but now I see that those tests don't depend
on it directly/have outweighing timeouts, so I completely agree, that
the test proposed is not elaborated enough to be committed.
Thank you!
Best regards,
Alexander
