daniel@mirsa.inria.fr (Daniel Dardailler) (02/27/89)
Xlib problem:
I want to wait for X events from more than one X server.
(it's for a communication program named xtalk, which act
basically like the unix-talk but with the X protocol and
windows/mouse convenience: independent window, drawing facility,
talk with several persons...)
The following loop is very time consuming (for 2 displays):
do {
if (QLength(dpy1)) {
XNextEvent(dpy1,&ev1);
DealWith(dpy1,&ev1);
}
if (QLength(dpy2)) {
XNextEvent(dpy2,&ev2);
DealWith(dpy2,&ev2);
}
} while (1) ;
If there is no event coming from dpy1 or dpy2, the Qlength test
always returns False(0) and the loop is VERY active.
It seems to me, after many trials, that this loop activity creates
'black hole'/'dead lock' problems on the client side.
A loop like:
do {
XSelectNextEvent(dpy_list, n_dpy, &ev, &disp); /* Blocking */
DealWith(disp,&ev);
} while (1)
would be better.
Have I missed something in the Xlib doc?
If not, I already think of a code implementation:
XSelectNextEvent(dpy_list, n_dpy, pev, pdisp)
Display ** dpy_list ;
int n_dpy ;
XEvent * pev ;
Display * pdisp ;
{
/** Loop for setting the appriopriate file descriptor in a read mask **/
for (i = 0, dpy = *dpy_list; i < n_dpy; i++) {
BITSET(r_mask, dpy->fd);
dpy++;
}
/** Multiple wait on these connections : blocking **/
select(MAXSOCK, r_mask, NULL, NULL, NULL);
/** Search for the display ready to be read **/
for (i = 0, dpy = *dpy_list; i < n_dpy; i++) {
if (r_mask | dpy->fd) {
*pdisp = dpy ;
break ;
} else dpy++;
}
/** Now read X event from this connection **/
XNextEvent(*pdisp,pev);
}
but I'm not a socket hacker, and there are certainly problems I don't see.
If such a call already exist in netland, I'd like to get it.
These problems will occur in all the situations where one X client is managing
the interface for more than one user: talk, chess-like games...
Perhaps one could think that this situation must never happened.
All comments and ideas on this issue are wellcome.
Daniel Dardailler | Email : daniel@mirsa.inria.fr
BULL Centre de Sophia Antipolis | Phone : (33) 93 65 77 71
2004, Route des Lucioles | Telex : 97 00 50 F
06565 Valbonne CEDEX France | Fax : (33) 93 65 77 66
--
Daniel Dardailler | Email : daniel@mirsa.inria.fr
BULL Centre de Sophia Antipolis | Phone : (33) 93 65 77 71
2004, Route des Lucioles | Telex : 97 00 50 F
06565 Valbonne CEDEX France | Fax : (33) 93 65 77 66 davidl@intelob.biin.com (David Levine) (03/09/89)
I'm following-up rather than replying via mail because I count the chances of a message getting through to France as about nil. > I want to wait for X events from more than one X server. > (it's for a communication program named xtalk, which act > basically like the unix-talk but with the X protocol and > windows/mouse convenience: independent window, drawing facility, > talk with several persons...) I'd say that this application is a good candidate for multi-processing. You have two asynchronous event sources. If you try to deal with them both in one (synchronous) process, you will either spend a lot of time in pointless looping (which is expensive of CPU time) or block on one event source while ignoring input on the other (which increases response time). I'd suggest you fork() two processes, one to watch each display, which communicate with each other via pipes or shared memory. This solution has nothing to do with X, really, but it's the best one I can think of offhand... David D. Levine BBBBBBBBB IIII IIII NNN NNNN TM Senior Technical Writer BBBB BBBB iiii iiii NNNN NNNN BBBBBBBBB IIII IIII NNNNNNNNN UUCP: ...[!uunet]!tektronix!biin!davidl BBBB BBBB IIII IIII NNNN NNNN MX-Internet: <davidl@intelob.intel.com> BBBBBBBBB IIII IIII NNNN NNN ARPA: <@iwarp.intel.com:davidl@intelob.intel.com>
daniel@mirsa.inria.fr (Daniel Dardailler) (03/10/89)
DL> is David D. Levine.
DD>> is me.
Thanks for your comments, David.
DD>> I want to wait for X events from more than one X server.
DD>> (it's for a communication program named xtalk, which act
DD>> basically like the unix-talk but with the X protocol and
DD>> windows/mouse convenience: independent window, drawing facility,
DD>> talk with several persons...)
DL> I'd say that this application is a good candidate for
DL> multi-processing.
Several processes was my first implementation. I only ask xpert for an
other possible solution with a centralysing one.
DL> You have two asynchronous event sources. If you
DL> try to deal with them both in one (synchronous) process, you will
DL> either spend a lot of time in pointless looping (which is expensive of
DL> CPU time) or block on one event source while ignoring input on the
DL> other (which increases response time).
It seems to me that the X server (itself :-) is "one (synchronous) process"
waiting for MANY "asynchronous event sources". What do you do with the
IPC select call?
The real problem is in fact that after the select call, I have problems
for reading a given number of events. Open issue.
DL> I'd suggest you fork() two
DL> processes, one to watch each display, which communicate with each
DL> other via pipes or shared memory.
I prefer to return to my first idea and have several independent processes
communicating with SendEvent requests. So they don't have to wait from
another socket than the X server one.
DL> This solution has nothing to do with X, really, but it's the best one
DL> I can think of offhand...
If I can (and I can) build my program with no other network protocols
than the X Window System Protocol-V11, it will be portable on ALL
X11 platform. Any other RPC mecanisms dealing with the same number of OS
is welcome.
Daniel Dardailler | Email : daniel@mirsa.inria.fr
BULL Centre de Sophia Antipolis | Phone : (33) 93 65 77 71
2004, Route des Lucioles | Telex : 97 00 50 F
06565 Valbonne CEDEX France | Fax : (33) 93 65 77 66
|chan@hpfcmr.HP.COM (Chan Benson) (03/14/89)
>> I want to wait for X events from more than one X server. >> (it's for a communication program named xtalk, which act >> basically like the unix-talk but with the X protocol and >> windows/mouse convenience: independent window, drawing facility, >> talk with several persons...) > >I'd say that this application is a good candidate for >multi-processing. You have two asynchronous event sources. If you >try to deal with them both in one (synchronous) process, you will >either spend a lot of time in pointless looping (which is expensive of >CPU time) or block on one event source while ignoring input on the >other (which increases response time). I'd suggest you fork() two >processes, one to watch each display, which communicate with each >other via pipes or shared memory. If you've got the select system call, you can multiplex input easily. You will end up holding up the other input source for as long as it takes you to respond to the other one, but it won't be ignored forever.
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (03/14/89)
If I can (and I can) build my program with no other network protocols
than the X Window System Protocol-V11, it will be portable on ALL
X11 platform.
We knew people would fall into this trap. It's very unfortunate. Just as
the world needed a unifying window mechanism, the world needs a unifying RPC
mechanism. Trying to use the X server as the RPC intermediary for things
it shouldn't be involved in is a mistake, plain and simple. You may think
it expedient (and it probably is), but it's still a mistake.