Path: utzoo!attcan!uunet!van-bc!ubc-cs!kiwi!bambi!janzen From: janzen@bambi.mpr.ca (Martin Janzen) Newsgroups: comp.windows.x Subject: Re: "wake up" XtAppMainLoop (X <-> C IPC) Keywords: XtAddInput, sockets Message-ID: <2401@kiwi.mpr.ca> Date: 25 Oct 90 20:19:44 GMT References: <9954@uhccux.uhcc.Hawaii.Edu> <12053@ibism.uucp> <1990Oct24.124130.3273@ncsuvx.ncsu.edu> Sender: news@eric.mpr.ca Reply-To: janzen@bambi.mpr.ca (Martin Janzen) Organization: MPR Teltech Ltd. Lines: 54 In article <1990Oct24.124130.3273@ncsuvx.ncsu.edu>, george@hobbes.ncsu.edu (George Browning) writes: >How would use use XtAddInput with Unix inter-process communication? >I need to use some System V IPC routines so a X parent interface can >talk with its Unix 'C' child program. > >The X interface forks off the child C program and I utilize the above >piping to capture the output of the C program. However, when an error >occurs I'd like to pass a message from the C program to the X interface >telling it to display an error dialog. I posted a message a few weeks ago about using IPCs in X programs, but can't find the original now. Anyway, you can make this work as follows (sorry for repeating myself...): 1. Parent process forks off a child process. 2. Child process creates an IPC queue and installs a signal handler for, say, SIGUSR1. 3. Parent sends one or more messages on the IPC queue, then sends SIGUSR1 to the child. 4. Signal handler in child removes and buffers IPC messages until the IPC queue is empty. 5. Signal handler in child calls XtAddWorkProc to register a work procedure, then exits. 6. When there are no outstanding X events for the child process, the work procedure is called. 7. The work procedure processes the first buffered message. 8. If there are more buffered messages, the work procedure returns False, so that it will continue to be called whenever the child's X event queue is empty. 9. If the last buffered message was processed, the work procedure returns True, so that it is deregistered until the next SIGUSR1. This approach has two benefits: 1. The IPC queue is emptied quickly (good because IPC resources are limited). 2. Messages are processed only when no X events are outstanding, so the application's response time to X events is not substantially reduced. Ciaran McHale (mchale@cs.tcd.ie, I think) pointed out a possible problem when using signals with System V; namely, that system calls may be interrupted by a signal, so that they return EINTR. Some software will loop until a non-EINTR status is returned, but other software which is not as defensively coded may break. The above technique works fine on SunOS 4.1, but your system may complain. Are there any X Consortium types or other X gurus out there who know whether Xlib handles interrupted system calls under System V correctly? How about the Athena and OSF/Motif widget libraries? ------------------------------------------------------------------------------- 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)