Path: utzoo!attcan!utgpu!watserv1!watmath!mks.com!dale
From: dale@mks.com (Dale Gass)
Newsgroups: comp.unix.questions
Subject: Re: screen program information
Message-ID: <1990Sep16.021433.27054@mks.com>
Date: 16 Sep 90 02:14:33 GMT
References: <24491@adm.BRL.MIL> <7598:Sep1407:49:4190@kramden.acf.nyu.edu>
Reply-To: dale@femto.mks.com (Dale Gass)
Organization: Mortice Kern Systems, Waterloo, Ontario, Canada
Lines: 80

In article <7598:Sep1407:49:4190@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>In article <24491@adm.BRL.MIL> Chauhan@system-m.phx.bull.com (Ardaman Chauhan (TDC)) writes:
>>           I downloaded the screen program from the net a while back and
>> found it very useful.  I have a question about the detach/attach feature
>> of the program by which you can detach a process and after wards
>> reattach to the same process from some other terminal/login.
>
>It sets up blocking IPC files, either named pipes or bound UNIX-domain
>sockets. All communication goes through the files. Reconnecting is
>just a matter of reopening the files.

Not quite so.  The sockets are only used for passing relatively
infrequent control messages (for creating new screen sessions by
running screen within a screen window, for reattaching, and for sending
error messages).

When screen starts, it forks into two processes, one of which does all
the screen work.  The second process is a dummy process which is used
solely for suspend/detach/resume support.  When one suspends or
detaches screen, the main screen process goes into the background, and
either stops (for suspend) or kills (for detach) the dummy process;
since the dummy process still has the user's login terminal as it's
controlling terminal, the shell that started screen will be notified,
and regain control.  (The main screen process is still lurking in the
background at this point).

Looking at the screen source code, it's not entirely obvious when the
main program goes into the background; it does this in a somewhat
subtle manner, by closing all file descriptors and then disassociating
itself with the controlling terminal with an ioctl() call.  Once in
the background, it simply processes incoming messages through the
control socket until it is no longer suspended (at which point it goes
back to it's main purpose of shuffling characters between the user's
controlling terminal and the screen sessions' pseudo-terminals).  

The messages which tell screen to continue (MSG_CONT and MSG_ATTACH)
cause screen's main process to open the user's login terminal.  Since all
it's files were close at this point, this causes the user's login
terminal to become the controlling process for screen.  Thus, screen
effectively has control of the user's terminal again.

The reattach messages are sent in one of two ways; a "screen -r" will
send this message, as well as "fg %1" (or any similar method of
continuing stopped processes), which will continue the stopped dummy
process.  (This second method will only work if screen was suspended,
not detached.)  The dummy process traps the SIGCONT; when a SIGCONT
occurs, it sends the reattach message to the main screen process (which
should be waiting for such a message in the background).

No special processing (or closing/reopening) is required for the screen
sessions during a suspend/detach.  They will continue processing until
they attempt to get input from the pseudo terminal, at which point they
will block, or until they send enough output to fill up the pty's
buffer, at which point they will also block.  When screen is restarted,
it will handle all pending output from, and sending input to the screen
sessions.

>(Of course, this adds an unnecessary layer of communication.

There is only one layer of communication; the screen program passing
characters from the user's login tty, and a session's pseudo-terminal.
The socket operations happen very infrequently, and should impose
little or no processing overhead during normal use.

In porting screen to Interactive Unix Sys V, I removed the
suspend/detach/reattach code for the sake of simplicity.  It reduced
the code size by about 600 lines, and made things a lot more readable.

Screen's source can be a bit intimidating at first; however, most of
the confusing stuff is related to the detach/reattach feature.  Once
one understands how this works, the rest of the code is quite
striaght forward.  Studying and understanding screen's source is very
educational; it exercises a lot of useful unix concepts (controlling
terminals, pseudo terminals, job control, sockets, signals, termcaps, 
interprocess communication, terminal modes, login records, environments,
load average, curses-like screen management, etc.)

-dale

dale@mks.com uunet!watmath!mks!dale