[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Core signal handling in a GUI setting results in unhandled SIGCHLD
From: |
Daniel J Sebald |
Subject: |
Core signal handling in a GUI setting results in unhandled SIGCHLD |
Date: |
Mon, 27 May 2013 13:14:49 -0500 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16 |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Core signal handling in a GUI setting results in unhandled SIGCHLD,
Daniel J Sebald <=