[Octave-bug-tracker] [bug #53513] graphics.cc-tst FAIL

[Pantxo Diribarne]

Follow-up Comment #19, bug #53513 (project octave):

I'll try to sketch the way Octave interpreter thread (T2 hereafter) interacts
with the Qt's GUI thread (T1 hereafter).

When a figure (or an ui* object) needs to be initialized, updated or
finalized, the ObjectProxy (in T2) sends a signal. Depending on the context,
we connect the signal to ObjectFactory::createObject, in case of
initialization, or to the corresponding Object::update/finalize slots (all in
T1). Since signals and slots live in two different threads, they will by
default be treated asynchronously in two different Qt event queues.

The first consequence is that all ObjectProxy::initialize/update/finalize
methods (in T2)  will generally return before the operations in T1 have been
successfully done. This bug and bug #53644 are illustrations of situations
where *we can't live with this asynchronous behavior*.

For printing (and getting pixels) we have solved the above issue by forcing
the signaling methods and corresponding slots to run synchronously. Basically
we use a Qt::BlockingQueuedConnection which locks the emitting thread (T2)
until the slot have been processed in T1.

Unfortunately we cannot apply this method to
ObjectProxy::initialize/update/finalize since the corresponding slots rely on
the interpreter thread T2 being awake:
* we need to be able to change some values in the graphics_object properties
(instanciated from T2). This is either done directly (we lock a mutex and call
graphics_objet::properties::set_xxx) or we post a graphics event which will be
processed later in T2. 
* we need to be able to ask the interpreter to run graphics callbacks. This is
done by posting a graphics event.

For the sake of completeness, the graphics event queue is implemented using
readline and is supposed to be flushed only when "drawnow" (and a few other
functions) is requested.

To summarize, I think the question is "how do we make sure signaling methods
in ObjectProxy don't return before their corresponding slots actually do?".
ATM I only can say *what we cannot do*: lock T2 using a mutex or a "while
(condition_not_met) {}".


    _______________________________________________________

Reply to this item at:

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

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