interrupts
The Beach Bum
jfh at rpp386.Dallas.TX.US
Sun Sep 11 00:22:20 AEST 1988
In article <373 at sdrc.UUCP> gpkinman at 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 at rpp386.Dallas.TX.US) HASA, "S" Division
"If the code and the comments disagree, then both are probably wrong."
-- Norm Schryer
More information about the Comp.unix.questions
mailing list