Re: CVS commit: src/tests/syscall

[christos%zoulas.com@localhost (Christos Zoulas)]

On May 21,  3:34pm, jmmv%NetBSD.org@localhost (Julio Merino) wrote:
-- Subject: Re: CVS commit: src/tests/syscall

| On 5/21/11 3:19 PM, Christos Zoulas wrote:
| > In article<20110521083602.GA24777%NetBSD.org@localhost>,
| > Julio Merino<jmmv%NetBSD.org@localhost>  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