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

[Dan Sebald]

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

I put a conditional statement in bold because I don't know how this Qt toolkit
and the multithreading is designed (nor do I care to know at this point). 
Member functions can be executed from one thread or another (the restriction
being that graphics can only be done in Qt's main thread), but if you are
saying Figure code is only executed from one thread, then that is fine.  The
point still holds about semaphores, though.  Even in the graphics thread,
using Qt's signal/slots rather than blocking the execution of code might be
better.

>From Canvas.cc:


            // FIXME: should we use signal/slot mechanism instead of
            //        directly calling parent fig methods


>From ObjectProxy.cc:


    // The ObjectProxy is generally ran from the interpreter thread
    // while the actual Figure (Object) lives in the gui thread. The
    // following ensures synchronous execution of the Figure method and
    // allows retrieving a return value.



    // FIXME: The following may fail for obscure reasons, see bug #53328.
    //        In absence of a solution, we retry twice before calling
error().


Then there are callback methods:


    void close_figure_callback (void);
    void copy_figure_callback (const std::string& format);
    void save_figure_callback (const std::string& file);


which I presume are coming from the worker thread, not the main thread.

The Figure::updateFigureToolBarAndMenuBar() code I listed below:  Can you see
how difficult it is to tell that "m_blockUpdates = true;" is meant to stop
some recursion?  Where is the "if (m_blockUpdates) return;"?  It's in some
other function.  One has to infer there is a possible recursion.  The
alternative interpretation is that there is something asynchronous occurring
that might do an update if that m_blockUpdates is not set.

Folks want to ditch other toolkits, but Qt toolkit hasn't become robust over
the course of half a decade and several release versions.  These little added
delays, multiple tries, etc. simply are wasting effort in my opinion.

    _______________________________________________________

Reply to this item at:

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

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