Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!decwrl!wam.UMD.EDU!stripes
From: stripes@wam.UMD.EDU
Newsgroups: comp.unix.questions
Subject: Re: Need help spawning a child
Message-ID: <8906271634.AA22055@cscwam.UMD.EDU>
Date: 27 Jun 89 16:34:45 GMT
References: <1661@apt.UUCP> <873@cbnewsl.ATT.COM> <12131@bloom-beacon.MIT.EDU> <14972@pasteur.Berkeley.EDU> <12244@bloom-beacon.MIT.EDU>
Distribution: usa
Organization: (just a tad)
Lines: 29

In article <12244@bloom-beacon.MIT.EDU> jik@athena.mit.edu (Jonathan I. Kamens) writes:
[stuff deleted]
>>Also, does anyone know what will happen to my sleeping process after
>>the signal handling call? Will it go back to sleep, or continue as if
>>it were given the alarm signal? What would be the effect of having
>>the signal handler send the alarm signal to the process?
>
>If a call to sleep() is interrupted by a signal for which a signal
>handler has been established, then the sleep() will resume where it
>left off after the signal handler exits.  I am fairly sure this will
>happen on all architectures; I just tested it on BSD, so I know it
>will happen there.
According to Bach's "The Design of the Unix Operating System", SysV
calls that are interupted by a signal return an error, this is true
under Ultrix as well where it returns EINTER, or someting like that.
For sleep() it looks like a good idea, but for everything else even
Mr. (or is it Dr?) Bach seems to admit that BSD's restart-syscall-after-
catching-signal is nicer.
In this case a simple "for(;;) sleep()" would do, even 'tho I prefer
to use a label and a goto just to answer a Kernal Kludge with a User Kludge.
>Jonathan Kamens			              USnail:
>MIT Project Athena				432 S. Rose Blvd.
>jik@Athena.MIT.EDU				Akron, OH  44320
>Office: 617-253-4261			      Home: 216-869-6432
-- 
           stripes@wam.umd.edu          "Security for Unix is like
      Josh_Osborne@Real_World,The          Mutitasking for MS-DOS"
      "The dyslexic porgramer"                  - Kevin Lockwood
		  Looking for a termcap entry for a PC running APL*PLUS...