Open PureTryOut opened 4 years ago
Hmm, it's definitely doing something it's not supposed to. We see it takes around 1.25 seconds to return even though it has a timeout of 0.1. What are the specs? Perhaps a cpu slowdown caused the parts not wrapped in the timeout to take longer than normal
Sorry for my late response. I'm not sure what the specs are, this is being ran on the Gitlab CI of Alpine Linux and every architecture is ran on it's own machine.
The failing architectures are x86, ppc64le, armv7 and aarch64.
From looking at the code, creating the subprocess and tearing it down won't be part of the timeout, and from experience that can take a not insignificant amount of time, especially on a contested CPU or if an HDD has to load data (the case for me).
I would increase the time difference that's asserted to something like 5 seconds, it's unlikely that a bug will cause it to timeout later, it's more likely that it won't timeout properly at all.
On Alpine Linux, some architectures (not all of them, e.g. it works fine on x86_64) seem to fail on
test_train_timeout_subprocess
:I'd think assert with those values would be less than 1 so equal to true, but maybe it doesn't like the
.
for some reason?