Re: XForms: forking a child

Steve Lamont (spl@szechuan.ucsd.edu)
Wed, 27 May 98 07:04:04 PDT

# To subscribers of the xforms list from spl@szechuan.ucsd.edu (Steve Lamont) :

> Now.. if I fork off the program in main(), will my callbacks still be able
> to work? It is the callbacks that send the appropriate string to the
> program..

Yes, if you confine the interaction between the program and XForms to
only one process -- multiple processes trying to talk to the server
over the same descriptor will cause the dreaded "Xlib async error".

> if I fork the program after the fl_do_forms.. would that work?

Yes, though you may wish to fork before intializing XForms or the
fl_do_forms() just to avoid instantiating a lot of duplicated data
structures which will be useless in one of the processes.

You may want to ask yourself whether this elaboration is really
necessary, though. Why can't the callbacks themselves just process
the strings? Do things *really* have to operate asynchronously?

I think you may find a little redesign of your algorithms at this
point will save you a whole load of debugging headaches in the
future. Asynchronous processes are often terribly difficult to debug
due to things like race conditions.

If you need to do work while the GUI is just sitting there waiting for
a user input or response, consider using the idle callback mechanism
built into XForms. This mechanism allows you to do small bits of work
while the GUI is otherwise idle. It does require a certain amount of
overhead in state saving and restoring (though static variables can
often alleviate a lot of this) and sometimes a bit of redesign of the
algorithm but I find it's a very useful mechanism.

spl
_________________________________________________
To unsubscribe, send the message "unsubscribe" to
xforms-request@bob.usuf2.usuhs.mil or see
http://bob.usuf2.usuhs.mil/mailserv/xforms.html
XForms Home Page: http://bragg.phys.uwm.edu/xforms
List Archive: http://bob.usuf2.usuhs.mil/mailserv/list-archives/