lim@wiliki.eng.hawaii.edu (Lim Kok Kian) (10/20/90)
I'm sure this has been asked before and I am sure there got to be a way to get around with the following problem I have : In my application I fork a child and do something and the child process will generate data and after so many data generated I want the parent process which is the application to be able to read or get the data and display that on the appication screen. My question is : Is there a way to wake up the XtAppMainLoop from the child .... say may be using some kind of signal ? Any Help would be appreciated ... but please email me directly cause I didn't keep up with this newsgroup! Thanks aloha --lim
lcp@ibism.UUCP (Larry Poleshuck) (10/24/90)
In article <9954@uhccux.uhcc.Hawaii.Edu>, lim@wiliki.eng.hawaii.edu (Lim Kok Kian) writes: > I'm sure this has been asked before and I am sure there got to > be a way to get around with the following problem I have : > > In my application I fork a child and do something and the child > process will generate data and after so many data generated > I want the parent process which is the application to be able to read > or get the data and display that on the appication screen. > > My question is : Is there a way to wake up the XtAppMainLoop from > the child .... say may be using some kind of signal ? > > Any Help would be appreciated ... > but please email me directly cause I didn't keep up with this newsgroup! > Thanks > > aloha > --lim Create a pipe for communicating with your child. Your child writes to the pipe and your parent calls XtAddInput with the XtInputReadMask. When data appears on the pipe the function specified by XtAddInput will be executed. You then read() on the pipe. Be careful to check that data has come across the pipe. -- Larry Poleshuck Citibank 111 Wall Street New York, NY 10043 Phone: 212-657-7709 Fax: 212-657-0068 E-Mail: uunet!ibism!lcp
george@hobbes.ncsu.edu (George Browning) (10/24/90)
>Create a pipe for communicating with your child. Your child writes to >the pipe and your parent calls XtAddInput with the XtInputReadMask. When >data appears on the pipe the function specified by XtAddInput will be >executed. You then read() on the pipe. Be careful to check that >data has come across the pipe. > >-- > >Larry Poleshuck 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. Thanks for any help, george -- ------------------------------------------------------------------------ | o | George Browning george@hobbes.catt.ncsu.edu | o | | o | NC State University Raleigh, NC | o | ------------------------------------------------------------------------
moss@brl.mil (Gary S. Moss (VLD/VMB) <moss>) (10/26/90)
In article <1990Oct24.124130.3273@ncsuvx.ncsu.edu>, george@hobbes.ncsu.edu (George Browning) writes: |> 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 did basically what you are trying to do by telling the C program to append errors to a temporary file which I had already opened for writing errors from the front-end X interface. I use fopen to open the file for writing and freopen to open it for reading in the front end, then call XtAppAddInput right before XtAppMainLoop: (void) XtAppAddInput( apcon, fileno(errorfp), XtInputReadMask, displayLogMsg, (XtPointer) errorfp ); displayLogMsg plops the text into an AsciiTextWidget. You could also set up a pipe for the child's stderr to go to which XtAppAddInput would read from as Larry Poleshuck stated in his note. -Gary
janzen@bambi.mpr.ca (Martin Janzen) (10/26/90)
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)