In article <20110521083602.ga24...@netbsd.org>, Julio Merino <j...@netbsd.org> wrote: >On Wed, May 18, 2011 at 12:30:24PM +0000, Christos Zoulas wrote: >> In article <4dd39547.9010...@julipedia.org>, >> Julio Merino <j...@julipedia.org> wrote: >> >On 5/18/11 4:15 AM, Christos Zoulas wrote: >> >> Module Name: src >> >> Committed By: christos >> >> Date: Wed May 18 03:15:12 UTC 2011 >> >> >> >> Modified Files: >> >> src/tests/syscall: t_pselect.c >> >> >> >> Log Message: >> >> Don't depend on the atf timeout stuff, do it ourselves. >> > >> >Why? Could atf do something better here? >> >> 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. > >You can override the timeout by setting the 'timeout' metadata property >to a different value. > >> 2. I need to do some cleanup if there is a timeout (kill the stuck process). >> How do I register a cleanup function? > >Use ATF_TC_WITH_CLEANUP and then provide an ATF_TC_CLEANUP function for >your test case. Be aware that cleanup runs in a different process than >the body, so the only way to transfer state is through a file in the >current directory. > >> 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. christos
