Path: utzoo!attcan!uunet!husc6!psuvax1!burdvax!sdcrdcf!trwrb!aero!venera.isi.edu!raveling
From: raveling@vaxa.isi.edu (Paul Raveling)
Newsgroups: comp.windows.x
Subject: Re: X11 and multiple processes
Message-ID: <5679@venera.isi.edu>
Date: 10 Jun 88 15:53:15 GMT
References: <25516@bbn.COM>
Sender: news@venera.isi.edu
Reply-To: raveling@vaxa.isi.edu (Paul Raveling)
Organization: USC-Information Sciences Institute
Lines: 42

In article <25516@bbn.COM> milliken@bbn.com (Walter Milliken) writes:
>
>I have a (hypothetical) program which consists of many (possibly a
>hundred or more) Unix processes.  Each of these processes would like
>to do output to the X server.  All are children of a single process.
>I can see two possible ways of handling this:
>
>1) The original process calls XOpenDisplay and lets all the children
>inherit the socket to the X server.

	This approach suffers from each process having its own
	instance of Xlib data.  I tried it once about a year ago
	on 10.4, and -- as expected -- it didn't work.

>2) Each child calls XOpenDisplay itself, and uses its own private
>socket to communicate with the server.

	This works well for output, but you have to be careful
	about input.  The safest way to avoid input deadlocks
	due to event selection from multiple processes it to centralize
	event handling in one process.
	
	... which adds yet another layer of interprocess communication.
	Tracing a mouse move from device driver to X server to network
	daemon to client -- and now to a client subprocess -- suggests
	why typical X/Unix systems have a poor ratio of response time
	to hardware speed.  Your multiprocessor should be a good
	solution -- sounds like you can totally eliminate those slow
	Unix context switches, and I presume it has hardware help
	for either data flow between processors or shared memory,
	or both.

	In the case of the HP systems we're using, which probably
	are typical, the connection-per-process approach also costs
	extra memory for buffers in the network daemon.  If yours
	needs 30K per connection, as ours does, you may need a
	couple megabytes of virtual (if not real) buffers.


---------------------
Paul Raveling
Raveling@vaxa.isi.edu