zaccone@psuvax.UUCP (08/04/83)
In an earlier article, I described some problems that I was having with
sigset, sighold and sigrelse. Since I wrote that article, I've
discovered that I don't really understand how these routines work.
Therefore, I'm going to restate my problem and ask for more general
help.
I'm trying to write to a device (via 'write') with both TANDEM and RAW
modes set. I would also like to catch the SIGINT signal, but I don't
want any I/O operation to be interrupted.
Right now, I'm trying something like this:
sigset(SIGINT, fn);
sighold(SIGINT);
some code with writes in it
sigrelse(SIGINT);
Even with this code, some write operation gets interrupted and does not
return normally (# of bytes attempted != # actually written).
Why is this happening? What am I doing wrong?
Rick Zaccone
Penn State University
{allegra, burdvax}!psuvax!zacconethomas@utah-gr.UUCP (Spencer W. Thomas) (08/06/83)
Right now, I'm trying something like this: sigset(SIGINT, fn); sighold(SIGINT); ... some code with writes in it sigrelse(SIGINT); Even with this code, some write operation gets interrupted and does not return normally (# of bytes attempted != # actually written). This is clearly a confusing situation. What the sighold/sigrelse pair guarantee you is that the write will have actually written as many characters as it said it did. It may only do a partial write, though. Without the sighold/sigrelse pair, the write might say that it had written 100 characters, while it had actually written only 47. This is clearly much harder to recover from. =Spencer
lund@ucla-ats@sri-unix.UUCP (08/06/83)
From: Laurence G. Lundblade <lund@ucla-ats>
The difficulty is with the combination of TANDEM and RAW modes.
In RAW mode all characters are passed with no special treatment including
^s and ^q. The result of using RAW and TANDEM modes together is just
what you got. The tty driver will send the ^s but never the ^q so
it looks like things hang. This will also happen if you combine
the normal fully cooked mode with TANDEM. So TANDEM only works
with CBREAK mode.
....Larry
ARPA: lund@ucla-locus
UUCP: {ucbvax,ihnp4}!ucla-s!lundJPAYNE@BBNG.ARPA@sri-unix.UUCP (08/07/83)
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?