[comp.windows.x] Multithreaded X programs

xg00@bunny.UUCP (Xev Gittler) (04/11/89)

With the advent of X window terminals and the like, there are going to
be a lot of people using the same machines for their 'home machines'
under X. What I was wondering was, has anyone done any work on making
some of the utilities that a lot of people are going to be running
(eg. xclock, xbiff, etc) into some sort of single server process?

The way I envision this is that when a user starts up an xclock, it
connects to an xclock 'server', and gives it all the necessary
information, and dies. The xclock server will keep track of who it is
serving, and take care of handling multiple windows on multiple
screens. This could even work with only one server on a local network.

Does anyone have any comments on this type of idea?


-- 
					Xev Gittler
					xg00@gte.com, or
					xg00%gte.com@relay.cs.net

reed@eds.COM (Brad Reed) (04/12/89)

>From: uunet!husc6.harvard.edu!bunny!xg00  (Xev Gittler)
>Organization: GTE Laboratories, Waltham, MA
>Subject: Multithreaded X programs (eg xclock)?
>
>The way I envision this is that when a user starts up an xclock, it
>connects to an xclock 'server', and gives it all the necessary
>information, and dies. The xclock server will keep track of who it is
>serving, and take care of handling multiple windows on multiple
>screens. This could even work with only one server on a local network.
 
I think what you are refering to is a reentrant program that can
serve multiple users.  Although the xclock example may not be a 
practical one, it does get the point across.  Another example may be
a sychronous communication gateway that allows access to multiple
channels by giving each user his/her own xterm.  I see no reason
why this could not be done.  This could be useful for very large
programs where multiple instantiations are not practical.

Brad Reed                   |  (313) 265-6525
EDS/TSD, 750 Tower Dr.      |  Arpanet: reed@edsews.eds.com    
Troy, MI 48007-7019         |  UUCP:    uunet!edsews!reed