Test failure in test_train_timeout_subprocess about padatious

[MatthewScholefield]

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

[PureTryOut]

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.

[ChlorideCull]

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.

#15 seems related.