Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!apple!vsi1!altnet!uunet!munnari!otc!metro!ipso!stcns3!stca77!peter
From: peter@stca77.stc.oz (Peter Jeremy)
Newsgroups: comp.unix.wizards
Subject: Re: sleep(3) uses longjmp and SIGALRM
Message-ID: <303@stca77.stc.oz>
Date: 10 Oct 88 07:33:10 GMT
References: <1988Sep28.135914.25444@lsuc.uucp> <823@philmds.UUCP>
Reply-To: peter@stca77.stc.oz (Peter Jeremy)
Organization: Alcatel-STC, Alexandria, AUSTRALIA
Lines: 23

In article <823@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes:
>In article <1988Sep28.135914.25444@lsuc.uucp> dave@lsuc.uucp (David Sherman) writes:
>> [ Interactions between sleep(), SIGUSER, longjmp(), pause() ]
> [ isn't longjmp() ]
>What may certainly cause you trouble is the setting of the alarm clock
>in sleep(); this will conflict with your setting of it, unless it is
>implemented clean enough to restore the original alarm time and setting
>of the interrupt handler. If it isn't, why not write your own?

Looking at my XENIX system, sleep() will save and restore your alarm()
setting.  I did discover a bug with some of my code that used sleep(1)
for short timeouts - occasionally it would stop.  When I looked at sleep()
closely, I found that there is a hole between the alarm() and pause() calls
(about 20 usec on a 8MHz 80286 from memory) that would occasionally let the
alarm() timeout before it paused - hence the pause() waited until the next
signal.  A bit embarrasing...  I got around it by using nap() or longer
sleeps.  I suspect the bug exists in all library versions of sleep(), so
it may be worth checking if you use 'sleep(1);' at all.
-- 
Peter Jeremy (VK2PJ)         peter@stca77.stc.oz
Alcatel-STC Australia        ...!munnari!stca77.stc.oz!peter
41 Mandible St               peter%stca77.stc.oz@uunet.UU.NET
ALEXANDRIA  NSW  2015