michael@stb.uucp (Michael Gersten) (01/14/90)
What EXACTLY happens to a program when a window change occurs? What EXACTLY happens to input queues/terminal lines? I have two programs that can detect a change in the active window. One prints "EXIT" and exits the program. There is no string "EXIT" anywhere in the program; at that point, unless some signal that I'm not expecting is killing the program there is no way to leave without printing a message. The other program is "less", and if it is reading a pipe when the active window changes, then it aborts reading the pipe and thinks it is working with an empty file. Any ideas? Michael -- Michael denwa!stb!michael anes.ucla.edu!stb!michael "The 80's: Ten years that came in a row."
bdb@becker.UUCP (Bruce Becker) (01/14/90)
In article <1990Jan14.053423.29887@stb.uucp> michael@stb.UUCP (Michael Gersten) writes: | |What EXACTLY happens to a program when a window change occurs? What |EXACTLY happens to input queues/terminal lines? | |I have two programs that can detect a change in the active window. |One prints "EXIT" and exits the program. There is no string "EXIT" |anywhere in the program; at that point, unless some signal that |I'm not expecting is killing the program there is no way to leave |without printing a message. | |The other program is "less", and if it is reading a pipe when the active |window changes, then it aborts reading the pipe and thinks it is working |with an empty file. | |Any ideas? The window system sends the "SIGWIND" signal to process involved in a window change. Here's the entry in "/usr/include/sys/signal.h" - #sccs "@(#)uts/kern/sys:signal.h 1.1" [...] #define SIGWIND 20 /* window change */ [...] It looks like these programs are catching the signal and doing something unuseful with it. Or else there's some system bug... -- ,,,, Bruce Becker Toronto, Ont. w \$$/ Internet: bdb@becker.UUCP, bruce@gpu.utcs.toronto.edu `/c/-e BitNet: BECKER@HUMBER.BITNET _/ >_ "Money is the root of all money" - Adam
michael@stb.uucp (Michael Gersten) (02/01/90)
In article <13571@cbnews.ATT.COM> res@cbnews.ATT.COM writes:
:In article <1990Jan28.174303.3448@stb.uucp> I wrote
:>[ Discussion about window switching flushing typeahead. One person
:> suggested using viraw in ksh. ]
:>
:>This does not help other programs. In general, is there a way to avoid
:>flushing input AND OUTPUT queues when SIGWIND occurs (which seems to
:>be when it happens).
:
:The underlying reason I believe this is the way it is, is that there is only
:one set of clists for the keyboard, not one per window. If the window
:manager left the keyboard buffer intact, then input destined for one window
:would be read by the next, as soon as you typed a return in the new window.
There is a simple solution to this. Maintain one set of clists per window.
The manual says that typeahead is not flushed when you switch windows,
but is kept around for that window to read. So the manual implies
seperated input queues.
Alas, now that the new fixdisk is out, we'll have to wait another year
to fix this :-)
Michael
--
Michael
denwa!stb!michael anes.ucla.edu!stb!michael
"The 80's: Ten years that came in a row."