octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #50795] octave-gui hangs on exit


From: Kuba Ober
Subject: [Octave-bug-tracker] [bug #50795] octave-gui hangs on exit
Date: Fri, 16 Feb 2018 10:23:22 -0500 (EST)
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) AppleWebKit/604.5.6 (KHTML, like Gecko) Version/11.0.3 Safari/604.5.6

Follow-up Comment #2, bug #50795 (project octave):

(This is a general reference-style comment)

I haven't looked at the code yet, but generally speaking the primary reason to
derive from `QThread` should be to make it a RAII class, i.e. to have
something like:


MyThread::~MyThread() {
  requestInterruption();
  quit();
  wait();
}


A RAII class is generally always-destructible, and is used to control the
resource's lifetime by extension. A `QThread` is three statements short of
that requirement :). `MyThread` can always be safely destructed, as long as
the code that runs in it behaves "sanely".

Such a thread can be owned by the main thread, and it will do the "right
thing", i.e. not have UB, as long as a few precautions are taken.

The thread's default implementation of `run()` spins an event loop. Whatever
runs inside the thread shouldn't block - since it will by extension block
`wait()` from the thread-owning thread.

Qt's idiom for "do some work continuously" is a zero-duration timer. Ideally,
octave's "main" code could be invoked in such an inverted-control fashion,
i.e. it would have a `doWorkChunk()` entry point. That's how most async code
has to work these days anyway.

As a fallback, the "main" could have locus of control, and invoke a callable
to check whether it should return control. This callable would simply return
`QThread::currentThread()->isInterruptionRequested()`. This can be done by
reimplementing `MyThread::run()`, or using the  run-in-a-thread construct
<https://stackoverflow.com/a/21653558/1329652> to start the interpreter
there.

I have to take a look and see if this is in the "easy fix" category - this
code does not have to be buggy or behave "strangely". Unfortunately, Qt
documentation doesn't always make it obvious how things should be done so that
they work OK.

Having the `fprintf` hack means that the bug is still there :(

    _______________________________________________________

Reply to this item at:

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

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]