Path: utzoo!attcan!uunet!lll-winken!csd4.milw.wisc.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!eds.COM!reed
From: reed@eds.COM (Brad Reed)
Newsgroups: comp.windows.x
Subject: Re:  Multithreaded X programs (eg xclock)?
Message-ID: <8904121317.AA24281@eds.com>
Date: 12 Apr 89 13:17:18 GMT
Sender: daemon@bloom-beacon.MIT.EDU
Organization: The Internet
Lines: 21

>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