Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!rice!uw-beaver!ubc-cs!kiwi!bambi!janzen
From: janzen@bambi.mpr.ca (Martin Janzen)
Newsgroups: comp.windows.x
Subject: Re: Awaiting _non_ X events, was Re : XtAddTimeOut() ....
Message-ID: <2324@kiwi.mpr.ca>
Date: 31 Aug 90 02:02:31 GMT
References: <9008231943.AA01202@crc.skl.dnd.ca> <141292@sun.Eng.Sun.COM> <4039@husc6.harvard.edu>
Sender: news@eric.mpr.ca
Reply-To: janzen@bambi.mpr.ca (Martin Janzen)
Organization: MPR Teltech Ltd.
Lines: 60

In article <4039@husc6.harvard.edu>, moghe@husc4.HARVARD.EDU (moghe m) writes:
> [stuff about polling and XtAddTimeOut deleted...]
>
> In the bad-old-days-before-X one would use this select()
> in the main loop to wait on Keys, Mouse, Timeout or
> whatever other events on any file descriptors were of
> interest. But now, if you have an X application which
> also needs to handle events other than X events, how
> does one do it? Lets say you want the X application to
> await on a message on a socket in addition to handling
> events from the X-server. Lets say that the message
> on the socket updates the screen.
> 
> Now one could use an auxiliary process to collect the message
> and XsendEvent() it to the X-applicaion via the X-server,
> but that seems such a round-about way to go. Is there a
> more direct way to await _NON_ X events in the X main loop?
> If so, are there any traps?
> 
> Email comments accepted.
> 
> moghe@husc4

As Ken Lee (klee@wsl.dec.com) points out, you can use XtAppAddInput (or
just XtAddInput) to wait for input on sockets, files, pipes and so
forth.  For other kinds of input, such as signals, IPC messages, shared
memory, etc., you may have to do a bit more work.

For example, I just wrote a program that talks to an old server task
through an IPC queue (yeah, I know...).  You probably don't want to
duplicate the kind of inter-process communication I describe here, but
you might find the technique for handling input messages useful.

Anyway, the sequence of events is as follows:

  - My application starts up, creates an IPC queue, registers a SIGUSR2
    handler, and sends an IPC message to the server's queue to register
    my program's new IPC queue id and pid (this part's pretty ugly :-).
  - When the server has data for my program, the server enqueues an IPC
    message and sends a SIGUSR2 signal to my program.
  - My SIGUSR2 handler dequeues all IPC messages and buffers them, then
    registers a work procedure using XtAddWorkProc (see also O'Reilly
    Volume Four, Section 8.5).
  - The work procedure gets called as soon as there are no X events out-
    standing, and processes the next buffered message.
  - If there are more messages, the work procedure returns False so that
    it will get called again.  (It's better to process one message at a
    time, to allow X event processing to continue.)
  - If there are no more messages, the work procedure returns True, so
    that it is deregistered until the next SIGUSR2.

If your application is receiving *huge* numbers of X events continually,
the response time could be affected, but I've found that this works
really well.  Hope this gives you some ideas...

-------------------------------------------------------------------------------
Martin Janzen                  Voice:    (604) 293-5309
MPR Teltech Ltd.               FAX:      (604) 293-5787
8999 Nelson Way                Internet: janzen@mprgate.mpr.ca
Burnaby, B.C. CANADA  V5A 4B5            (134.87.131.13)