SXT's and SWTCH

Stephen J. Friedl friedl at vsi.COM
Fri Jan 6 18:57:57 AEST 1989


In article <329 at mpx2.UUCP>, erik at mpx2.UUCP (Erik Murrey) writes:
> 
> I would like to be able to send a signal, or an ioctl() request to
> "shl" to SWTCH to the layer manager.

I think that this is not possible.  We have used sxts moderately
extensively, and we had to have a child send an agreed-upon signal
to the manager to relinquish control.  This is indeed a bummer --
it couldn't have been that hard to add to the driver [?].

> My question is: how does a session manager (i.e. "shl") receive the
> SWTCH hot-key from the tty driver?  A quick glance through
> signal.h/sxt.h/termio.h reveals nothing.  Does it just do a read on
> the controlling channel which blocks until SWTCH?

Once the layer manager has multiplexed all the children onto the
real tty, it makes one current with SXTIOCSWTCH and then goes
to sleep until it is current with SXTIOCWF.  When the user hits
control-Z, channel 0 is automatically made current.  Since this
is usually the manager, it prints its little >>> prompt and you
can pick another layer.

A couple of notes: (first) the SWTCH character -- control-Z, usually --
is never actually seen by either manager nor managed children,
and (second) in no case are signals used in the entire sxt system
outside of the normal killing of child processes upon the
manager's request.

SXTs are handy for a lot of things, and *we* couldn't live without
them, but they are not job control.

     Steve

P.S. - we inferred most of what we know by lots and lots and lots
of T&E. Anybody with *real* information is certainly encouraged
to correct the bugs that may lurk within the above.  Someday I'll
have to go back to school so I can look at source again :-).

-- 
Stephen J. Friedl        3B2-kind-of-guy            friedl at vsi.com
V-Systems, Inc.        I speak for me only      attmail!vsi!friedl
Santa Ana, CA  USA       +1 714 545 6442    {backbones}!vsi!friedl
-------Nancy Reagan on Usenix in San Diego: "Just say *go*"-------



More information about the Comp.unix.questions mailing list