Core signal handling in a GUI setting results in unhandled SIGCHLD

[Daniel J Sebald]

References:

Thread
GUI file dialog freeze
http://octave.1599824.n4.nabble.com/GUI-file-dialog-freeze-td4653201.html

bug #38305, file dialog causes crash
https://savannah.gnu.org/bugs/index.php?38305

patch #7949: octave-gui freezes for 30+ seconds when trying to display a 
new documentation tab
https://savannah.gnu.org/patch/?7949

Thorsten tracked down the source of the problem with the GUI freezing 
for a couple minutes and then the GUI acting erratically.  It has to do 
with SIGCHLD signal handling being overridden by the Octave core 
(worker) thread in the GUI setting and is pretty high priority because 
I'm fairly certain there will be other ways this problem manifests 
depending upon how the native OS treats various events and how the 
system is configured that might use child processes.

The discussion is here:

https://savannah.gnu.org/bugs/index.php?38305

and Thorsten's observation for preventing the Qt File Dialog freeze is 
to not set this signal handler in the routine install_signal_handlers ():

Lines 472-474 (sighandlers.cc)
#ifdef SIGCHLD
// octave_set_signal_handler (SIGCHLD, sigchld_handler);
#endif

I will explain what the issue is, as I understand, then list the 
possible options for a solution.  This really needs someone with the 
experience of setting up Octave's signal handlers to know what is the 
proper thing to do.

Thorsten has in his system a Samba server.  We suspect that Qt with KDE 
with Samba is launching some child process to seek out file information 
on the Samba server.  The child process finishes after a fraction of 
second and then a SIGCHLD signal is sent back to the parent process 
indicating completion of the child process.

If I'm understanding correctly, Octave worker is in a separate thread 
(as opposed to process) so that any modifications to signal handling in 
the worker thread also affects the GUI thread.  In other words, the 
install_signal_handlers () routine in Octave core is overriding Qt's 
signal handling configuration.  Although Octave core (worker) signal 
handling is setup to keep track of the child processes *it* creates 
using the objects:

class
OCTINTERP_API
octave_child

and

class
OCTINTERP_API
octave_child_list

I suspect that any child process arising from a GUI thread action will 
not be entered into the Octave core signal handling octave_child_list. 
Hence, Octave core cannot appropriately respond to the signal because it 
won't be able to identify the origin--which brings about the "QProcess: 
Destroyed while process is still running." notification after a couple 
minutes.  I suspect there could be an unknown number of situations where 
the GUI thread creates child processes in some system on which Octave 
GUI has yet to be tested.

Well, here are the options that I see:

1) Disable setting the SIGCHLD signal handler in Octave core if launched 
inside the GUI.  I.e.,

if (! start_gui)
  octave_set_signal_handler (SIGCHLD, sigchld_handler);

This would work if all that sigchld_handler does is try to make the OS 
happy about acknowledging child processes, and this would be the easiest 
change.  But if Octave does some type of processing or Java or something 
via a child process, then the signal handler has to be installed so that 
Octave can get the processed information from the child process.

2) Stepping back one level, the whole of signal handling could be 
disabled inside Octave core by making the following change inside 
octave_initialize_interpreter ():

  if (! embedded)
    {
      if (! start_gui)
        install_signal_handlers ();
    }
  else
    quit_allowed = false;

That would require the condition of #1 but also any other signals would 
no longer need to be important or we would need to figure out some way 
to pass signals from Qt's default signal handler to the worker thread. 
Moderate change.

3) Figure out some way to determine that Qt GUI thread is creating child 
processes and pass that information to Octave worker thread to put in its

class
OCTINTERP_API
octave_child_list

That sounds awful (but I may be wrong).  It would mean figuring out that 
some native OS component is using a child process, then writing some 
octave_link method for sending the PID and so on to Octave worker thread 
so that it can be put in the list.  Then there is still the issue of 
knowing how to acknowledge the signal seeing as it might be doing 
something important.  Better to just leave Qt developers to deal with 
all that.

4) Maybe create a QProcess for Octave worker as opposed to a QThread. 
This might have the advantage of separating the signal handling for the 
GUI and for the worker which would mean no alterations of any kind to 
signal handling is need (well not really because of the following 
point), but it also has the major disadvantage of necessitating a whole 
new strategy for communicating between the GUI and the worker.  I don't 
want people having nightmares, so I'll disqualify this one as an 
alternative.

Dan