Describe the bug
The timeout feature introduced in #104 is not getting reset properly. The code checks for a timeout in the copy of the worker dict, but this has just been deleted from there:
signal.setitimer(signal.ITIMER_REAL,
cwrk.pop("timeout"))
cwrk.pop('fun')(job, **cwrk)
if "timeout" in cwrk:
signal.alarm(0) # cancel the alarm
To Reproduce
(will add later)
Expected behavior
Timeout should be reset.
Actual results
Timeout is not reset, which means the next or next next plugin may be interrupted due to the earlier timeout still being active.
Environment Info:
Additional context
The problem is masked if the next plugin also uses a timeout, because setting a new signal replaces the previous one. That's why I (Gerrit) never realised the problem, but it's quite clear that it exists reading the source code.
Writing unit tests for this is a little bit tricky.
Describe the bug
The timeout feature introduced in #104 is not getting reset properly. The code checks for a
timeoutin the copy of the worker dict, but this has just been deleted from there:To Reproduce
(will add later)
# Your code hereExpected behavior
Timeout should be reset.
Actual results
Timeout is not reset, which means the next or next next plugin may be interrupted due to the earlier timeout still being active.
Environment Info:
Additional context
The problem is masked if the next plugin also uses a timeout, because setting a new signal replaces the previous one. That's why I (Gerrit) never realised the problem, but it's quite clear that it exists reading the source code.
Writing unit tests for this is a little bit tricky.