Re: [XForms] Is there interference between XForms running in different processes?

[Jens Thoms Toerring]

Hi,

On Fri, Jul 06, 2018 at 05:43:39PM -0700, Peter Rowat wrote:
> Should it be possible to have two or more processes, each running an
> XForms-based animation with a control panel ? Or would you expect some
> interference between different XForms invocations in different processes?

Well, first of all, there are no "XForms invokations". XForms
is a library that becomes part of programs that was linked with
it. And, as with any library, each libraru that "copy" of it has
it's own, completely "private" set of data, states and resources.
Any interaction on this level is impossible (or the whole thing
about virtual memory would be broken;-)

> =====
> A rough description of my actual problem is here:
> 
> There are several animation displays in different processes each running
> their own XForms gui. Each animation has a control panel to adjust its’
> geometry, using the same XForms invocation. In addition, there is a compute
> intense data source in another process that feeds the animations via
> sockets, with an XForms gui for overall speed control.
?
> My problem is that sometimes the speed control becomes “dead” — unresponsive
>  — and sometimes the animation controls become dead. I haven’t figured out
>  why.
>
> Could it be due to interference between XForms running in different
> processes?
> I’m using setitimer as per the XForms manual pp. 300-301 to set the speed. 

Direct interference between the copies of XForms linked to
programs running as different processes is impossible. But,
of course, they all compete for one of the most important
resources, CPU time.

You seem to do a lot of work, triggered by a signal received
from setitimer(). This work can't be done in a signal handler
(as there's only a very limited set of functions that can be
called in signal context, and none of XForms belonging to them).
Thus, by doing e.g.

  setitimer(ITIMER_REAL, interval);
  fl_add_signal_callback(SIGALRM, gui_signal_handler, &myData);

(forget about fl_app_signal_direct() for the moment, which
is only needed when you need to do something in the signal
context, I'll come back to it later) you make XForms install
a signal handler for SIGALARM. In that handler it just in-
crements a counter to keep track of how many times SIGALRM
has been received.

Now, when there's a moment of time, XForms will call your
gui_signal_handler() function as many times as the SIGALRM
signal has been received in the meantime (decrementing its
counter accordingly). One possible scenario for what you see
is that these SIGALRM signals get produced at a higher rate
than they can be handled in your gui_signal_handler() func-
tion. For each signal received gui_signal_handler() is cal-
led once - the internal counter is decremented once each time.
But if during the execution of gui_signal_handler() one or more
new signals get caught, the part of XForms delaing with the
signals, running until the counter is down to 0, will never
get done. And then the rest of the GUI seems to be dead as
XForms has no spare time left to deal also with that.

The chances of that happening increase, of course, the higher
the overall system load is as each of the processes get a smaller
amount of CPU time.

And, of course, there could also be intermittent phases, where
the system load is temporarily very high and the work for the
signal handling is all that gets done, but things returning
to "normal" once the system load is reduced (as then the
work for a signal can be done again faster than timer signals
get raised).

There's no fits-it-all solution to this (except "run less
programs at the same time" and "buy a faster machine";-)
But often you may be able to reduce the work that needs to
be done for a signal.

Let's assume your animation consists of displaying some
rotating object. And to do that you calculate how it
looks like after a rotation by some angle phi and then
you draw that. Perhaps the time it takes to calcuate the
rotation by phi isn't mch shorter than for an angle of
2*phi or 3*phi. Then you could do

  sig_atomic_t rotation_steps = 0;

  void timing_critical_task(int sig) {
      if (rotation_steps++ = 0)
          fl_signal_caught(sig);
  }

  void gui_signal_handler(int sig, void *data) {
      int steps = rotation_steps;
          rotation_steps = 0;
      /* Rotate and draw for steps * phi in one single step */
      ...
   }


   /* And now it makes sense to use fl_app_signal_direct()... */

   fl_app_signal_direct(1);
   setitimer(ITIMER_REAL, interval);
   signal(SIGALRM, timing_critical_tasks);
   fl_add_signal_callback(SIGALRM, gui_signal_handler, &myData);

So, here you deal with the signal yourself first (by calling
fl_app_direct(1) and installing your own signal handler for
it. By counting yourself via 'rotation_steps' how many times
the signal was received and only calling fl_signal_caught()
(which just increments the internal counter of XForms for
the number of signals received and thus controls how many
time gui_signal_handler() will be called) you achieve that
your gui_signal_handler() function is invoked only once by
XForms. That can reduce the time spent for that task quite
significantly as all the calculations and the whole drawing
is done only once.

In case things are slow gui_signal_handler() will be called
for each timer signal. But if things get tight it will be
called less often, thus leaving more time for other tasks
like reacting to the rest of the user interface. Of course,
that may make the animation look less smooth, but that's
the price you'll have to pay.

Perhaps something like this can also be used in your case?
As I understand it you're producing data in some other pro-
cess. Perhaps you can simply discard some of those data and
just display the last set of them?

                          Best regards, Jens
-- 
  \   Jens Thoms Toerring  ________      address@hidden
   \_______________________________      http://toerring.de