On May 21, 3:34pm, j...@netbsd.org (Julio Merino) wrote: -- Subject: Re: CVS commit: src/tests/syscall
| On 5/21/11 3:19 PM, Christos Zoulas wrote: | > In article<20110521083602.ga24...@netbsd.org>, | > Julio Merino<j...@netbsd.org> wrote: | >>> 1. It did not work. What units is the timeout anyway? I waited 2 seconds | >>> and 2 minutes and it did not fire. | >> | >> It's in seconds. The default is 300. | > | > I think the unit is too long for modern hardware. Imaging having 300 tests | > needing 1 second timeouts. | | Yes, the timeout thing is broken. It should really be a specification | of the test case size (e.g. 'small', 'large') and allow the user to | define his timeout preferences for every class, because they will vary | from machine to machine. | | That said, I don't see why you'd want to have 300 tests needing 1-second | timeouts. If a test times out, it's broken, so the only thing I can | deduce is that you'd have 300 broken tests ;-) | | >>> 3. No matter how the timeout is done (unless you start a watcher process and | >>> kill -KILL the test process) it can break (masking signal mask, changing | >>> timers, catching signal). | >> | >> The timeout is enforced from atf-run, not from inside the test case; it is | >> already using a helper process in a sense, so it should work. If it doesn't, | >> it is a bug that I'd like to debug. | > | > Revert the latest revision in the test and boot a kernel before the pselect | > changes, and see it getting stuck. | | Any particular revision? I have a machine that hasn't been updated for | at least two weeks; will that be enough? Oh sure. revision 1.1 christos
