stopping in CBREAK.

[Henry Spencer]

> 	Another note asked how to put a CBREAK task back
> into CBREAK after stopping and restarting. All the editors
> I've seen trap SIGSTOP in a specific handler, where they
> save whatever state they want to save and then kill
> themselves (with a SIGSTOP). Upon return they reset the
> signal, repaint their screen, do the CBREAK ioctl, and
> return. This, of course, assumes the Berkeley job control;
> I don't think this is possible under S5, since there are
> no user level hooks. I guess there the kernel "knows"
> to reset your state correctly, right? Hmmm......

As I understand it, the SysV layers stuff doesn't *have* to "reset your
state" correctly, because it is keeping separate state for each layer.
Makes sense, right?  Why should multiple independent processes have to
share a common state, when they each want to see different values of it?
Especially when it means imbedding specialized code into each one to
do context switches correctly.

This is not to claim that SysV does things right, of course.  Multiple
SysV layers still share one major element of state:  the screen.  When
multiple-process interaction is done right, as in various window systems,
all screen activity goes through central coordination, and *no* shared
state is visible.  Each process thinks it has its own (virtual) terminal.
This is really the only reasonable way to do things.  Consider the similar
case of multiple processes accessing a shared disk:  chaos and madness
result unless the sharing is centrally coordinated.  Ignoring the issue,
or making the user processes do the coordination themselves, is a recipe
for trouble.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry