Date: Sun, 18 May 1997 20:33:22 +1000 From: Bruce Evans <bde@zeta.org.au> To: ache@nagual.pp.ru, peter@spinner.dialix.com Cc: bde@zeta.org.au, cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org, cvs-lib@FreeBSD.org, peter@FreeBSD.org Subject: Re: cvs commit: src/lib/libc/gen sleep.c Message-ID: <199705181033.UAA01135@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>FWIW, I can't find any other sleep() implementation that always returns >zero like ours has done up to now. Ours was just buggy. >> In any case, _ignored_ signals should not interrupt sleep. > >Hmm.. Are we doing this?? Yes, tsleep() ignores them too. >Yes, if a SIGALRM arrives during sleep() from an outside source, we should >end the sleep rather than exit if the alarm signal isn't trapped. Only for backwards compatibility. >However, I don't see how to do this without races while using nanosleep(). >It could be possible to get a SIGALRM right after installing the handler >but before the nanosleep() starts. The old method doesn't have this problem :-(. sigsuspend()/sigpause() has exactly the right semantics for preventing the race. However, there's nothing you can do about SIGALRMs sent before the handler is installed. nanosleep() and the old sleep() have the same problem - alarms can't be relied on to terminate the sleep, because they may arrive before the sleep begins (perhaps due to scheduling delays). The best that you can do is to catch them so that you don't get killed. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199705181033.UAA01135>