inheriting processes from other ttys

[Carsten Bormann]

In article <10091 at ulysses.homer.nj.att.com> cjc at ulysses.homer.nj.att.com (Chris Calabrese[rs]) writes:
() In article <352 at tub.UUCP>, cabo at tub.UUCP (Carsten Bormann) writes:
() > 
() > The plan was to do it in two steps:
() > 
() > 1) Implement detaching from a ``screen'' process and attaching to it
() >    from a different terminal of the same type.
() > 2) Enhance ``screen'' to be able to change terminal types mid-river, which
() >    in combination with (1) would allow you to e.g. detach from an h19
() >    and attach from a vt100 (as long as the screen dimensions and other
() >    critical parameters remain the same).
() 
() I've thought of doing this also.

You now can all stop thinking about step 1, my posting (and the
perceived need by the growing ``screen'' user community :-) motivated
Oliver to implement it.

We are, however, not yet completely happy with the solution:
Making ``screen'' detachable involves always having two ``screen'' processes.
The parent process essentially is there to make the login shell (or /etc/init
for the daring) wait for the next detach command.  The child process contains
the functionality of screen as it is now.  There is no way to unite the 
two processes for the following reasons:

1) The detach command must make screen terminate (at least from the point
   of view of the shell or /etc/init).  The standard way to handle this
   in the daemon world would be to fork and have the parent exit; unfortunately
   there is no way to inherit the parental relationship screen had with the
   programs in the windows to the new child process.  Therefore, the child
   process must manage the forking of the window processes from the outset;
   for minimum change, Oliver gave it the entire functionality.  Now if
   UNIX provided a way to bequeath children to a new child...

2) The attach command must be a command callable from the shell (currently
   it is called screen -r, r for resume).  This command must stay alive
   as long as the old child process is handling the terminal; otherwise
   the shell would compete with screen over the tty.  Now if UNIX provided
   a primitive to replace the contents of a process with a different
   process (exec from a running process)...

The new parent process of the screen utility does not wake up except for
implementing Quit, Detach, and Suspend, so it is not too much overhead;
on the other hand, having the entire thing in one process as before would
have been more aesthetically pleasing (and would provide less potential
for strange states where the two processes do not agree what's up).

Oliver probably will make available a patch to the last version of
screen when we have had a week or so of alpha-testing.  When step 2
has been implemented and other cleanup has been done, a new posting
to comp.sources.unix might be in order.


A few parting comments on Chris' posting:

() One probelm with this approach is speed, of course.

The solution is to buy a computer that is fast enough.
Seriously, the main reason Oliver does not use his own program too
much is that it slightly slows down terminal I/O on this box.
This does not discourage me the least...

() Another thing is that it would be much easier to impliment
() using the terminfo database, instead of termcap, but it's
() not available under BSD, or Xenix (versions I've used).

When System V release N includes a pty driver (or equivalent
functionality, such as a STREAMS-based terminal driver), we can talk
about moving ``screen'' to System V.  Until then, tough luck (and no
terminfo).

Regards, Carsten Bormann
-- 
Carsten Bormann, <cabo at tub.UUCP> <cabo at db0tui6.BITNET> <cabo at tub.BITNET>
Communications and Operating Systems Research Group
Technical University of Berlin (West, of course...)
Path: ...!pyramid!tub!cabo from the world, ...!unido!tub!cabo from Europe only.