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

[Dan Sebald]

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

You may be on to something, but I'm hoping you meant that this patch works
without the need of the fprintf() call, i.e., no


+  /* fprintf to stderr is needed by macOS */
+  fprintf(stderr, "\n");


If I remove the above line from the patch you posted, Octave GUI still exits
fine in linux--no surprise, I guess.

I probably disregarded this connection:


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


thinking it just some innocuous extraneous call at worst.  However, that might
have been the source of the problem all along.  What this connection means is
once the main thread finishes, it's going to emit a signal that the main
thread (itself) should delete later.  That does seem like an odd construct,
though, doesn't it?  I mean, this might be an unconventional thing to do, and
as such the Qt developers may have a bug in this construct that went untested.
 It's conceivable that m_main_thread can't change the status of delete-later
once it has reached the stage of issuing a finished().

...

In fact, I'm looking at the documentation for Qt here (it's the link from post
#3):

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

Look at the second method they suggest for doing this worker-thread
communication.  It's the *worker* thread that has its finished() signal
connected to its deleteLater() slot:


void MyObject::startWorkInAThread()
{
    WorkerThread *workerThread = new WorkerThread(this);
    connect(workerThread, &WorkerThread::resultReady, this,
&MyObject::handleResults);
    connect(workerThread, &WorkerThread::finished, workerThread,
&QObject::deleteLater);
    workerThread->start();
}


and, importantly, the WorkerThread must be subclassed from QThread, i.e.,
derived from.

In Octave, it looks like the main thread is connected to itself (not the
worker thread) and the main thread is just a QThread, not a derived class. 
The current configuration is probably some unconventional thing for which it
might be no surprise (to the designers perhaps) that this fails.

Anyway, let me know if your revised patch still works if the fprintf() is
removed.  If not, we may have to redo this worker-thread setup as much as
possible similar to the examples given in the link above.  (Threads are
tricky, not deviating is a good idea.)

    _______________________________________________________

Reply to this item at:

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

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