Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!decvax!harpo!seismo!hao!hplabs!sri-unix!JPAYNE@BBNG.ARPA
From: JPAYNE@BBNG.ARPA@sri-unix.UUCP
Newsgroups: net.unix-wizards
Subject: problems with sigset, sighold and sigrelse.
Message-ID: <3939@sri-arpa.UUCP>
Date: Sun, 7-Aug-83 09:43:00 EDT
Article-I.D.: sri-arpa.3939
Posted: Sun Aug  7 09:43:00 1983
Date-Received: Mon, 8-Aug-83 19:36:50 EDT
Lines: 24

If you look at the code in the tty driver, you will see that ntyinput
calls flushtty(tp, FREAD | FWRITE) when the character typed is the
interrupt or quit character, and THEN it calls gsignal who calls
psignal who checks to see if the signal is held ...

This is exactly the problem I described a while ago, but one that
nobody seemed to have a solution for.  It is not a coincidence that
write says that it successfully wrote 100 characters.  ntwrite tries
to optimize its output by moving characters from u.u_base to an
internal buffer of size 100 (note the 100), and then, if all the
characters are simple printable characters, ntwrite does 1
b_to_q(its_buffer, OBUFSIZE, tp->t_outq).  There are two problems.
One is ntyinput calls flushtty (maybe wflushtty in certain cases would
be better), and the other is a little more complicated.  ntwrite calls
iomove to move the data from u.u_base to ntwrite's internal buffer.
iomove decrements u.u_count, so upon return from iomove, however many
bytes requested from iomove are logically written.  

Actually ntwrite calls
	b_to_q(its_buffer, UP_TO_LAST_PRINTABLE_CHARACTER, tp->t_outq),
so if UP_TO_LAST_PRINTABLE_CHARACTER happens to be 47, then 47 characters
stand a good chance of actually being sent to the terminal.

Do you believe all this?