Recovery possible from signal aborted write(2) ?

[Kenneth Almquist]

> Using systems 3 or 5, is there any way of deterministically restarting
> output to a tty that has been interrupted by a signal.
> 
> Scenario:
> 	Screen managing type program generating lots of escape sequences
> 	also is subject to receiving several signals a minute.  The
> 	program wants to buffer its output for effeciency, so it does
> 	write(2)s of say 50-100 characters at a time.  When it receives
> 	a signal, however, the write returns a -1, rather than indicating
> 	the number of characters actually output.  This makes it very
> 	hard to guarantee screen integrity while buffering output.
> 
> One obvious solution is to forgo buffering.  Any other suggestions?

Are you sure about this?  Vnews is a similar program and the only bug
reports that I have gotten have come from Version 7 systems.  I have
reproduced the vnews output routine below.  The code inside ifdefs is
for Version 7 systems since the problem you describe does indeed exist
in Version 7 and the best I could to was to turn off alarm signals
during output.  One complication with this sort of code is that if the
terminal is hung up, subsequent writes will always return 0.  There-
fore I test the variable hupflag (which is set when a hangup signal is
received) to avoid the possiblilty of an infinite loop.
				Kenneth Almquist


/*
 * Flush the output buffer
 */

vflush() {
	register char *p;
	register int i;
#if BSDREL <= 7 && USGREL < 30
	int svalarm = alarm(0);	    /* signals cause UNIX to drop characters */
#endif

	for (p = outbuf ; p < outnext ; p += i) {
		if (hupflag)
			break;
		if ((i = write(1, p, outnext - p)) < 0) {
			if (errno != EINTR)
				abort();	/* "Can't happen" */
			i = 0;
		}
	}
	outnleft = BUFSIZ;
	outnext = outbuf;
#if BSDREL <= 7 && USGREL < 30
	alarm(svalarm);
#endif
}