Xref: utzoo comp.unix.wizards:11052 comp.unix.questions:9161
Path: utzoo!attcan!uunet!husc6!mailrus!ames!killer!vector!rpp386!jfh
From: jfh@rpp386.Dallas.TX.US (The Beach Bum)
Newsgroups: comp.unix.wizards,comp.unix.questions
Subject: Re: interrupts
Summary: wrap your functions ...
Message-ID: <6403@rpp386.Dallas.TX.US>
Date: 10 Sep 88 14:22:20 GMT
References: <373@sdrc.UUCP>
Reply-To: jfh@rpp386.Dallas.TX.US (The Beach Bum)
Organization: HASA, "S" Division
Lines: 56

In article <373@sdrc.UUCP> gpkinman@sdrc.UUCP (Tim Kinman) writes:
>I would like to implement an alarm utility within my application
>but I am concerned about the side effects it will have on my existing code.
>
>It is my understanding that reads from a terminal, wait, and pause will return 
>an error condition when they are interrupted by an alarm.

correct.  they return an error (usually -1) and set errno == EINTR.  this
condition is easily checked for - BUT - must be checked for at every call
which could block.

>I have several questions...
>
>1. Are these the only system functions that will not resume where they left off
>   after the interrupt is complete?

functions which will return because of an interrupt will be so documented
in the manual.  read, write, open, close, ioctl, wait, pause, and many
more [ my unix manual by this terminal is snafu'd ... ]

the general rule of thumb is I/O on slow devices [ tty's ], any form of
wait or pause and any other call which can reasonably be expected to
block [ perhaps semwait? ] has the potential to return EINTR.

>2. Is this true on all flavors of UNIX? I recently heard that this is not a 
>   problem on System V.

i don't know of a UNIX(tm) variant which it is not a problem with.  the
solution is fairly portable across all unix systems since Way Back When(tm).
for example, here is a wait(2) which handles error returns:

#include <errno.h>

extern	int	errno;

int	w_wait (status)
int	*status;
{
	int	i;

	while ((i = wait (status)) == -1)
		if (errno != EINTR)
			return (-1);

	return i;
}

this function should be a drop-in replacement for any wait(2) call which
you want restarted after an interrupt.  i would suggest you add additional
features, such as an exit flag to force these calls to exit anyhow before
writing missle guidance software using this routine.
-- 
John F. Haugh II (jfh@rpp386.Dallas.TX.US)                   HASA, "S" Division

    "If the code and the comments disagree, then both are probably wrong."
                -- Norm Schryer