rhl@grendel.Princeton.EDU (Robert Lupton (the Good)) (10/24/90)
I have a number of programmes that spend most of their time doing other things, but also wish to keep an X-window up-to-date. In other words, the XEvent loop is not the main control loop. I am currently doing this by select()ing on input from the keyboard, timing out, and going off to look for XEvents with XCheckMaskEvent(); if there are none pending it's back to select(). It'd like to get a signal of some sort when an event is ready so as not to use up cycles continually (modulo the select() timeout) polling for input, but none seems to be mensioned in the Xlib manuals (specifically the O'Reilly ones). I am not looking for a server-specific hack, so maybe this isn't possible? Robert
mayoff@cs.utexas.edu (Robert Mayoff) (10/24/90)
In article <3540@idunno.Princeton.EDU> rhl@grendel.Princeton.EDU (Robert Lupton (the Good)) writes: >I have a number of programmes that spend most of their time doing other >things, but also wish to keep an X-window up-to-date. In other words, >the XEvent loop is not the main control loop. >I am currently doing this by select()ing on input from the keyboard, It is interesting that you are (apparently) taking input from stdin, not from the X window itself... >timing out, and going off to look for XEvents with XCheckMaskEvent(); >if there are none pending it's back to select(). >It'd like to get a signal of some sort when an event is ready so as not >to use up cycles continually (modulo the select() timeout) polling for >input, but none seems to be mensioned in the Xlib manuals (specifically >the O'Reilly ones). >I am not looking for a server-specific hack, so maybe this isn't possible? This should be easy for you to accomplish, since you are already selecting on the keyboard. Get the X socket file descriptor by using the ConnectionNumber macro on your Dislay pointer, and add it to your select file-descriptor mask. Before your select call, call XFlush. Then, select with no timeout (i.e., select should block). When it returns, check to see if the X socket file descriptor is set in the returned mask. If so, call your X event handler. If your other file descriptor is set in the mask, call your keyboard handler. Check both each time, because it is possible for both file descriptors to be set (if input comes in on both channels before you are up for execution again). I have used this technique several times on Suns and IBM RTs. -- /_ rob <mayoff@cs.utexas.edu> /_ Fun things to do with UNIX (#34 in a series): / while(!fork()) kill(getppid(), 9);
jg@crl.dec.com (Jim Gettys) (10/24/90)
What you want to do is operating system dependent, and as X is an O.S. independent specification as much as we could make it, we don't go into how to do what you want. Select(2) is the normal way to do this on BSD derived systems; select doesn't use cycles if nothing is happening. It sounds like you are already doing things in mostly a reasonable way. Unless your program goes compute bound for long periods, this should work fine. Remember to make sure the event queue is empty before calling select again. I don't understand why you need a timeout on your select. As to full signal driven stuff, look at sigio (though you better know what you are doing if you delve into signal driven applications); again, you better have BSD "safe signals" or equivalent to be able to safely write applications that are signal driven. -- Jim Gettys Digital Equipment Corporation Cambridge Research Laboratory
fgreco@dprg-330.GOVt.shearson.COM (Frank Greco) (10/24/90)
> I have a number of programmes that spend most of their time doing other > things, but also wish to keep an X-window up-to-date. In other words, > the XEvent loop is not the main control loop. > I'd suggest using the Xview notifier (it can be used without using Xview). There is an example in Dan Heller's XVPM describing a simple solution to the situation you describe. Frank G.