Date: Sun, 18 May 1997 14:20:10 +0800 From: Peter Wemm <peter@spinner.DIALix.COM> To: Bruce Evans <bde@zeta.org.au> Cc: ache@nagual.pp.ru, peter@FreeBSD.ORG, cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, cvs-lib@FreeBSD.ORG Subject: Re: cvs commit: src/lib/libc/gen sleep.c Message-ID: <199705180620.OAA04512@spinner.DIALix.COM> In-Reply-To: Your message of "Sun, 18 May 1997 11:29:42 %2B1000." <199705180129.LAA17474@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans wrote:
> >BTW, it seems I find possible reason (but not test it yet). It looks like
> >old sleep stops only by SIGALRM (sigpause in while loop) but new one stops
> >by _any_ signal, isn't it?
It's supposed to stop on any trapped signal with EINTR as near as I can tell.
> One difference is that non-defaulted SIGALRMs now kill the process
> instead of terminating the sleep. This breaks sleep(1). POSIX.1 may
> allow either behaviour (the behaviour is mostly unspecified so that BAD
> historiclal implementations using alarm() are standard). In particular,
> if SIGALRM is not generated be a previous call to alarm() and SIGALRM is
> not being ignored or blocked, then it is explicitly unspecified whether
> the signal has any effect other than causing sleep() to return. The case
> of SIGALRMs generated by alarm()s seems to be implicitly unspecified!
Hmm. Perhaps install a temporary dummy SIGALRM handler in the sleep.c stub
so that it doesn't die if there isn't one. The old setitimer way doesn't
mess with alarm(2), using nanosleep() wont change that.
> Bruce
The SVR4.0 man page for sleep(3c) says:
..
The routine is implemented by setting an alarm signal and pausing until
it (or some other signal) occurs. The previous state of the alarm signal
is saved and restored. The calling program may have set up an alarm
signal before calling sleep. [..guff about adjusting alarm(2)..]
..
ie: traditional sleep(3) behavior is that any signal interrupts the sleep.
The "principal of least suprise" probably suggests that we should prevent
any unhandled sigalarms from aborting the process by absorbing it within
the sleep->nanosleep wrapper.
Cheers,
-Peter
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199705180620.OAA04512>