[Octave-bug-tracker] [bug #50025] Octave window freezes when I quit Octave GUI

[Dan Sebald]

Follow-up Comment #3, bug #50025 (project octave):

Folks, I think this is more of an Octave proper-Qt-programming issue than it
is an OS X problem.  In particular, it is the proper sequence of shutting down
threads.  I looked at the system complaints in the bug report

https://savannah.gnu.org/bugs/?50795

and although the dump is so voluminous to really not be helpful, I do see
"pthread" and such in the list.

Let me try to illustrate what the issue probably is from looking at hunks of
code.

The following is from mainwindow.cc:


  connect (m_interpreter, SIGNAL (octave_ready_signal (void)),
           m_doc_browser_window, SLOT (load_info_file (void)));

  connect (m_interpreter, SIGNAL (octave_finished_signal (int)),
           this, SLOT (handle_octave_finished (int)));

  connect (m_interpreter, SIGNAL (octave_finished_signal (int)),
           m_main_thread, SLOT (quit (void)));

  connect (m_main_thread, SIGNAL (finished (void)),
           m_main_thread, SLOT (deleteLater (void)));

  m_interpreter->moveToThread (m_main_thread);

  m_main_thread->start ();
}


What I wanted to explore is whether not starting the thread results in a clean
thread.  But when I comment out the m_main_thread->start() line on Linux, the
GUI hangs and only kill -9 will stop it.  Well, that's bad in the sense that
Octave GUI should be much more graceful if the thread doesn't start properly. 
It doesn't seem far-fetched that a thread doesn't start, so here is another
thing to look at.  (My feeling is the whole startup/shutdown concept needs an
overhaul.)

Now, shutdown.  octave_finished_signal (probably emitted when the interpreter
is about to exit) is connected to "this" (i.e., the GUI main window)
handle_octave_finished().  That's fine, it's just letting the GUI know it's
done.

The m_main_thread finished() signal is connected to its deleteLater() slot. 
This is fine too, as it has become a typical construct, at least in this
prototypical example:

http://doc.qt.io/qt-5/qthread.html#details

Where I think the problem lies is this line:


  connect (m_interpreter, SIGNAL (octave_finished_signal (int)),
           m_main_thread, SLOT (quit (void)));


The m_interpreter is running *in the thread*, and it tells the thread to quit.
 The Qt documentation makes no mention of such a construct, but I'm imagining
that being an undefined sort of behavior.  Let's take a look at the prototype
example of how quit is used:


    ~Controller() {
        workerThread.quit();
        workerThread.wait();
    }


Notice it is the Controller, the thing that launched the worker thread, that
is issuing the quit.  The quit is not coming from within the thread.  But more
than that, and probably the key issue, is that the Controller can also wait on
the thread to finish.  If the GUI does not wait on the worker thread to
finish, somewhere in the exit process, then there is a good chance this is
problematic.  I suspect that is the source of failure for Mac OS X, i.e., that
threads are structured differently internal to the OS.

Notice with the signal/slot construct of accessing quit(), there is no
straightforward way of also doing a wait() somewhere.  This is why I'm saying
the exit process needs to be reworked.  Add to that the GUI should also
gracefully handle the thread not starting properly.  Also, the GUI should
gracefully handle the interpreter crashing and the interpreter not responding
at exit.  There is just a whole lot of work that needs to be done.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?50025>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/