Closed ibuclaw closed 4 years ago
LGTM although I don't know if tests are expected to take that long or if there is something profoundly broken and taking too long is just a symptom of that.
It's not reproducible locally, or at least, I did hit it when I was stepping through gdb to find out what might be throwing. It may well be that 15 seconds is enough for travis now, but I just picked a number that should be safe.
It depends what the intent of the timeout is for. Catching changes that cause a slowdown, or catching deadlocks?
Given that we have no control whatsoever in the machines running the tests and they can be infinitely slow, I guess it only make sense to have a timeout to detect (likely) deadlocks.
The travis build runs now exceed the current 10 second limit.
Similarly, have fixed the timeout callback to set
this.killed = true
as per the code documentation. If this was done in the first place, it would have saved a lot of debugging done to work out what the original cause was.