🚀 go-pugleaf

In article <14246@maslow.ptolemy-ri.arc.nasa.gov>, fineman@ptolemy-ri.arc.nasa.gov (Charles Fineman) writes:
|> 
|> I'm working on a performance visualization package and I would like to
|> give the user the option of displaying views on multiple screens. The
|> problem comes when trying to wait for events from the different
|> windows. If the windows are handled by different display servers, the
|> event wait loop turns into a spin-loop since there is no way to do a
|> blocking request for events from multiple servers (right???).
|> 
|> The only other solution I could see is to "fool" a display server into
|> believing that another, remote, display, is really just another screen
|> of this display. Has anyone toyed with this idea before? Would such an
|> extension fit into the exiting generic display server code elegantly?
|> 
|> Has anyone else come up with an interesting (and efficient) solution
|> to this problem?
|> 
|>         Chuck Fineman

I've gotten a couple of responses refering to toolkit functions. First,
how do the toolkit functions handle multiple displays? Do they spin-loop,
checking each display (in a non-blocking mode) each time through, or has
it been integrated into the X library so well that it can use a more 
intelligent method (i.e. select on a set of sockets)?

What about the case when the toolkit is not being used? Please, constructive
comments only! ;-)

	Thanks,

		Chuck Fineman