Test failure in test_train_timeout_subprocess

[PureTryOut]

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:

============================= test session starts ==============================
platform linux -- Python 3.8.3, pytest-5.4.2, py-1.8.1, pluggy-0.13.1
rootdir: /builds/PureTryOut/aports/testing/py3-padatious/src/padatious-0.4.8
collected 36 items

tests/test_all.py ......                                                 [ 16%]
tests/test_container.py ....sF.........                                  [ 58%]
tests/test_entity_edge.py .                                              [ 61%]
tests/test_id_manager.py ....                                            [ 72%]
tests/test_intent.py ..                                                  [ 77%]
tests/test_match_data.py ..                                              [ 83%]
tests/test_train_data.py .                                               [ 86%]
tests/test_util.py .....                                                 [100%]

=================================== FAILURES ===================================
______________ TestIntentContainer.test_train_timeout_subprocess _______________

self = <tests.test_container.TestIntentContainer object at 0xffff8f5d54c0>

    def test_train_timeout_subprocess(self):
        self.cont.add_intent('a', [
            ' '.join(random.choice('abcdefghijklmnopqrstuvwxyz') for _ in range(5))
            for __ in range(300)
        ])
        self.cont.add_intent('b', [
            ' '.join(random.choice('abcdefghijklmnopqrstuvwxyz') for _ in range(5))
            for __ in range(300)
        ])
        a = monotonic()
        assert not self.cont.train_subprocess(timeout=0.1)
        b = monotonic()
>       assert b - a <= 1
E       assert (3178089.64288705 - 3178088.391084973) <= 1

tests/test_container.py:149: AssertionError
=========================== short test summary info ============================
FAILED tests/test_container.py::TestIntentContainer::test_train_timeout_subprocess
=================== 1 failed, 34 passed, 1 skipped in 5.89s ====================

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?

[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.