[comp.windows.x] server?

coop@tygart.cerc.wvu.wvnet.edu (Cooperate) (11/24/90)

	Is that true that for every client that connects to a
X server, a child server process will be created? So every client has
its copy  of server? thanks for comments.

mouse@LARRY.MCRCIM.MCGILL.EDU (11/25/90)

> Is that true that for every client that connects to a X server, a
> child server process will be created?  So every client has its copy
> of server?

Definitely not in general.  No server I am familiar with works this
way, and I have never heard of one that does.

Given the way the server is required to work, it would be difficult to
implement.  In particular, clients are permitted to manipulate objects
(windows, pixmaps, etc) created by other clients; indeed, window
managers more or less *require* such capabilities, meaning that a
server that forks a child for each client would probably have some
major difficulty keeping the various processes in sync.  Not that it's
impossible, just that it's difficult enough that I would be surprised
to find anyone bothering.

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu

av@kielo.uta.fi (Arto V. Viitanen) (11/26/90)

>>>>> On 24 Nov 90 15:16:39 GMT, coop@tygart.cerc.wvu.wvnet.edu (Cooperate) said:


Cooperate> 	Is that true that for every client that connects to a
Cooperate> X server, a child server process will be created? So every client has
Cooperate> its copy  of server? thanks for comments.

Sounds odd. How about X-terminals and PC-servers, which can only have one
process, the server itself ?
--
Arto V. Viitanen				         email: av@kielo.uta.fi
University Of Tampere,				   	    av@ohdake.cs.uta.fi
Finland

jimf@SABER.COM (11/27/90)

|Cooperate> 	Is that true that for every client that connects to a
|Cooperate> X server, a child server process will be created? So every client has
|Cooperate> its copy  of server?

No, there's usually just one process although I could see someone
threading the server at some point.  There's no reason why a server
must run in more than one process and most do not.

This design brings about the most significant limitation with most
UNIX-based X servers -- they can only talk to as many clients as they
have available file descriptors.  This is not generally a problem
since newer UNIX's generally have 64 or more file descriptors per
process.

|How about X-terminals and PC-servers, which can only have one
|process, the server itself ?

If you check I believe you'll find that some (most?) X terminals
actually run a stripped-down kernel with a couple of processes,
typically telnet and the X server.  I'm certain that one of the major
X terminal vendors (NCD?) uses or used to use this architecture,
although it's been a long time since I was at that talk so I'm pretty
fuzzy on the details.  It's easier to do this than to modify your
basic server to handle remote logins and loading of fonts via NFS.

Happy hacking,

jim frost
saber software
jimf@saber.com