parlette@nas.nasa.gov (Edward B. Parlette) (12/17/90)
I am writing a program using straight XLib and need to be able to break out of the Event loop if I haven't received a keypress event within a certain amount of time. I have used alarm calls in the past for this and am wondering if this will cause a problem with XLib calls ?? I thought I saw a message on the new that claimed using signals with X was a bad idea but I have forgotten why. Can someone refresh my memory ?? Thanks. kelvin email: kelvin@calvin.larc.nasa.gov calvin.larc.nasa.gov
sivan@bpa_su10.Sbi.Com (Sivan Mahadevan) (12/18/90)
In article <1990Dec17.134238.26720@nas.nasa.gov>, parlette@nas.nasa.gov (Edward B. Parlette) writes: > I am writing a program using straight XLib and need to be able > to break out of the Event loop if I haven't received a keypress > event within a certain amount of time. I have used alarm calls > in the past for this and am wondering if this will cause a problem > with XLib calls ?? I thought I saw a message on the new that claimed > using signals with X was a bad idea but I have forgotten why. > kelvin email: kelvin@calvin.larc.nasa.gov > calvin.larc.nasa.gov In order to make use of signals in the manner you wish, you need to 1) Build a version of Xlib that is signal re-entrant 2) Take special precautions on the type of X calls made from within signal handlers. Xlib comes with LockDisplay and UnlockDisplay macros, #define'd to be empty. If you set macros these to block and unblock signals respectively (using sigblock() and sigsetmask()), then you have an Xlib that is re-entrant for a given signal. However, if you just do this, then you won't be able to catch any signals when waiting in the event loop (i.e., in XNextEvent()). Therefore, make sure you remove the LockDisplay and UnlockDisplay macros from XNextEvent(). You have to be careful to not do any "event management" within signal handlers, because with the above Xlib, XNextEvent() itself is not re-entrant. Therefore don't call any X*Event() routines from within signal handlers and don't call XSync() or XFlush() either. The best practice is to do as little X in the signal handlers as possible, and wait until you get back to main loop to do the work. -- Sivan Mahadevan Salomon Brothers Inc Bond Portfolio Analysis Analytical Applications Group One New York Plaza 44th Floor 212-747-5418 New York NY 10004 sivan@bpa_su10.sbi.com uunet!sbi.com!bpa_su10!sivan
klee@wsl.dec.com (Ken Lee) (12/19/90)
In article <1990Dec17.134238.26720@nas.nasa.gov>, parlette@nas.nasa.gov (Edward B. Parlette) writes: |> |> I am writing a program using straight XLib and need to be able |> to break out of the Event loop if I haven't received a keypress |> event within a certain amount of time. I have used alarm calls |> in the past for this and am wondering if this will cause a problem |> with XLib calls ?? I thought I saw a message on the new that claimed |> using signals with X was a bad idea but I have forgotten why. |> Can someone refresh my memory ?? Thanks. You can use signals with Xlib as long as you do not call any Xlib functions from your signal handler. If the signal interrupted a write to the server connection and then you send new requests in the signal handler, the server will get very confused. If you're just interested in timers, try a select() on the ConnectionNumber() and setting a timeout in the select(). Alternatively, you can use the timer facility in the X Toolkit. -- Ken Lee DEC Western Software Laboratory, Palo Alto, Calif. Internet: klee@wsl.dec.com uucp: uunet!decwrl!klee