XENIX <-> ULTRIX interrupts & traps

[Guy Harris]

> >1)  Which one is correct?  It's the same code, both C, so one must be
> >    wrong.
> 
> ABSOLUTELY NOT!  Library functions are exactly that:  library functions.

Correct.

> C does not specify how library functions must behave, or even what functions
> must be provided in an implementation's library.

Correct, but not if you're talking about ANSI C.  It actually *does* specify
some functions that must be provided, and how they behave.  One of these
functions is "signal"; however, since "read" is (fortunately) not one of
these functions, it does not specify what happens to a "read" when you
return from a signal handler.

> Now, if you browse through signal.h, you will note an error value called
> EINTR.  At least on BSD 4.2, if a signal arrives while read is awaiting
> data, read returns -1 and errno is set to EINTR:

Well, not really; if you browse through "errno.h" you'll find EINTR, but you
sure won't find it in "signal.h".

More to the point, under *some* circumstances, on BSD 4.2 (which is what
ULTRIX-32, at least, is derived from; XENIX, however, does not derive its
signal handling code from BSD 4.2), returning from a signal handler to a
"read" will cause the "read" to return -1 and set "errno" to EINTR.
However, in the most common circumstances, it won't.  With the older signal
mechanism that V7, S3, and S5-derived systems, such as XENIX, provide,
returning from a signal handler to a "read" will cause the "read" to return
-1 and set "errno" to EINTR.

(Actually, it's a combination of the signal and "read" mechanisms, and I
think in the S5R3 "streams" code, if the signal handler returns to the
"read" *after it has already transferred some data* the "read" will return
the number of bytes it transferred before being interrupted.  This is what
the signal and "read" mechanisms should have done all along; otherwise, you
have no idea how much data was transferred before the interrupt occurred.)

With the newer 4.2BSD and 4.3BSD signal mechanisms, if the "read" has not
transferred any data, and the signal in question has not been specified as
interrupting system calls, returning from the signal handler will cause the
"read" to be reexecuted.  If the read has already transferred some data, or
if the 4.3BSD feature that permits you to specify that particular signals
should interrupt calls like "read" has been used, returning from the signal
handler will cause the "read" to return -1/EINTR, just as it does with older
signal mechanisms.

> >2)  I'd prefer the program to function as it does under XENIX.  How can
> >I get it to not continue with the read when there was an interrupt during
> >the read?
> 
> Since read has returned -1, it seems you could examine the value of errno
> and repeat the read call if errno is equal to EINTR, viz.:

Since "read" hasn't returned -1, but has been repeated for you by the
system, you can't.
-- 
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy at sun.com (or guy at sun.arpa)