Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!ucsd!ucbvax!hplabs!hpfcso!hppad!kempff
From: kempff@hppad.HP.COM (John Kempff)
Newsgroups: comp.windows.x
Subject: Re: X-terminals & xinit
Message-ID: <2990007@hppad.HP.COM>
Date: 17 Feb 90 01:05:59 GMT
References: <14540003@acf4.NYU.EDU>
Organization: HP Panacom Automation Div Waterloo, Ont.
Lines: 70

> / hppad:comp.windows.x / wood@acf4.NYU.EDU (David Wood) /  5:53 pm  Feb  9, 1990 /
> 
> 
> 		Has anybody written a new xinit type tool for
> 	the X-terminals.  I began this and got about half way there
> 	but thought I'd ask around in netland to see if anyone
> 	has already done this.  The problem is that xinit always
> 	tries to run a server (or am I mistaken), but these X-terminals
> 	just need to have the .xinitrc (or .xsession) file started
> 	up.  Then when the person is done, this knew xinit could do
> 	a killpg() to kill all the clients.  That in fact is the 
> 	problem I'm experiencing with the X-terminals.  If you have
> 	novice user logout of one of these without killing all the
> 	clients they just hang around.  Enough said, does anybody
> 	have any comments.  Thanks.
> 
> 	p.s.	Perhaps it should be an extension to xinit.
>  -------------------------------------------------------------------------
>  David Wood					wood@acf2.nyu.edu
>  New York University				...!uunet!cmcl2!wood
>  212-998-3029
>  		"Brain. Brain. What is brain?" 
> 			Kara the Eymorg, "Spock's Brain", Stardate 5432.3
>  -------------------------------------------------------------------------
> ----------

Why use xinit to start sessions on the X terminals.  Xdm does the job
for me.

Before Xdm came out, I tried to modify xinit so that it will work with
remote X servers like X terminals.  I quickly gave up for two reasons.

1. The version of xinit that I had was written expecting the X server
   to be running on the same CPU as xinit.  The xinit program would
   startup the server as a child, then verify that it was running by
   doing an XOpenDisplay() on it.  After the server was running, the
   users .x11start script would also be executed as a child of xinit.
   It would then immediately wait for a childs death signal, then kill
   all process associated with both childs.  The big problem is that
   a Xterminal server is not executing locally.  There was no easy way
   of converting this program to detect the death of a remote server.

   Yes I could have detected the death of the server by polling it,
   reason 2 (below) came about before I got to writting a robust
   polling routine.

2. I also ran out of time and Xdm was just made available with X11R4.
   Xdm will automatically start up the clients on a remote X server
   after the user logins.  Now I can log into any X terminal in our
   building and have my own personal enviroment.

   Also  when you logoff with xdm, all the clients associated with
   that X session are also killed.  Logging off for me means shutting
   down one key window, ie a terminal emulator with special colours to
   indicate that it is the KEY window.  Bit of a pain if you accidently
   kill or logout of that window.

   What else could I you for :-).

The moral of the story is steal xdm.  It was written from the ground
up expecting remote X servers.

John Kempff               | ##    ## |  ######## /   ########
X Windows Support Eng.    |   #  #   | #######  /      #######
Panacom Automation Div.   |    #     | ######  /_    __ ######  H E W L E T T
Waterloo, Ontario, Canada |     #    | #####  /  /  /  / #####
                          |   #  #   | ##### /  /  /__/  #####
Email:kempff@hppad.hp.com | ##    ## | ######     /     ######  P A C K A R D
Phone:(519) 886-5320      |          | #######   /     #######
FAX:  (519) 886-8620      | TERMINAL |  ########/    ########