The latter happens in about 10% cases. It happens in lines:
t1 := Duration.now
verifyErr(TimeoutErr#) { pool.stop.join(100ms) }
t2 := Duration.now
verify(t2 - t1 <= 120ms) // here we fail
It means we want stop to trigger in 20ms. This is slightly above the time quantum in both Windows(1/64 sec) and Linux(10ms by default).
Suggested solutions:
Put a note that it's OK for this test to fail sometimes.
Increase time limit.
Use statistical approach, thus not enforcing hard real-time on environment.
brianSat 28 Aug 2010
Yeah that test sometimes fails on my MacBook. I was trying to balance keeping the test duration short without a long wait period, but still tight enough to test it still works.
I bumped up the time to 140ms - should provide a bit more wiggle room
vkuzkokov Sat 28 Aug 2010
Running test mentioned above on not the oldest PC in the world (namely Core2 1.8GHz with Ubuntu 10.04 upon it) may result in both:
and:
The latter happens in about 10% cases. It happens in lines:
t1 := Duration.now verifyErr(TimeoutErr#) { pool.stop.join(100ms) } t2 := Duration.now verify(t2 - t1 <= 120ms) // here we failIt means we want stop to trigger in 20ms. This is slightly above the time quantum in both Windows(1/64 sec) and Linux(10ms by default).
Suggested solutions:
brian Sat 28 Aug 2010
Yeah that test sometimes fails on my MacBook. I was trying to balance keeping the test duration short without a long wait period, but still tight enough to test it still works.
I bumped up the time to 140ms - should provide a bit more wiggle room
changeset