milliken@bbn.com (Walter Milliken) (06/09/88)
I was hoping one of the X gurus out there might be able to help me with a possible problem: 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. I'm not familiar with the protocol, the server, or the Xlib implementations, but I can see that with some design choices, there might be a problem. If, for example, state is kept by both the server and client on a per-connection basis, the client-side info would get out of sync in the various processes. 2) Each child calls XOpenDisplay itself, and uses its own private socket to communicate with the server. Since X identifiers are unique to the server, there's no problem with passing IDs around among the various processes, and presumably, they could all write to the same window. The problem here is that this approach uses *lots* of sockets, which may be a resource problem in the Unix implementation, and could also cause problems if the server keeps per-connection data without expecting someone to come along with *hundreds* of connections. Can the server run out of file descriptors in this case? In case you're wondering, the system in question is a parallel processor with up to 128 processors (the Butterfly GP1000). Users often run programs with one process per processor, all cooperating on the same computation. I'd like to have a workable strategy for handling X output from such programs. Any suggestions? ---Walter
mangerma@nmsu.CSNET (06/09/88)
Walter,
I am currently working on the same problem at the Computing
Research Laboratory at New Mexico State University. We have a 64
node Intel Hypercube and want to use X Windows to monitor the
processes running on each node.
Our front end processor is a Sun which controls all the
info with the outside world (of the Hypercube), so the
implemetation should not be that difficult.
We are also thinking of using X as a debugger of the
processes running on each node.
An aside, since we have a large network of Sun's (for New
Mexico) around 40... We are also thinking about using the Sun
Network as a parallel processor. Granted we have bandwidth
problems, limtited to 10 Mbits per second (ethernet). But X is
perfect for this since it is designed to have the server running
on one host and the processes running on all the rest, no need to
tie up those machines with the server. We are also anticipating
faster channels currently under development at Los Alamos, that
should give 80Mbits per second.
Both of these projects are in their infancy stage, as we
are coming up to speed with X11. However, we would be interested
in starting a newsgroup (mail group) of people interested in this
type of stuff. Anyone who has a network of computers on an
ethernet could potentially use that network (in the deep dark
hours of the night, when all those machines are sleeping) as a
parallel processor. X is great, because it can be used as the
basis for this powerful model of computation that is waiting to
be utilized in harmony. It is just implementation details !!
One of the applications we are using the hypercube for now
is to generate fractals. We are able to generate fractals on the
hypercube currently in about 5 minutes using the 64 nodes to full
capacity and a "hungry puppy" algorithm. Each node generates one
line of the fractal and when it is done, goes on to the next
available line that is waiting to be generated. The key is that
all nodes are always busy. The same computation on a Sun-3 takes
around 3 hours. Looking forward to hearing what other people are
doing.
Have a good one !
Michael Angerman
Computing Research Lab
New Mexico State University
Las Cruces, New Mexico 88001
505-646-5711
mangerma@nmsu.eduraveling@vaxa.isi.edu (Paul Raveling) (06/10/88)
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