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

[Dan Sebald]

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

What Pantxo is describing in Comment #13 and Rik in Comment #8 is what I meant
by Comment #4.  As an example, I look at the code and see pretty extensive use
of the variable "m_blockUpdates" throughout.  That variable is used in
Figure::update (int pId) as follows:


    if (m_blockUpdates)
      return;


and I see a process ID as an input, so I'm wondering (rhetorically) if this
routine is asynchronous.  *If that is the case*, that m_blockUpdates used all
about won't do much.  The m_blockUpdates variable approach will prevent
recursive calls, but not asynchronous issues.  For example, hypothetically
speaking, imagine if this short routine is called asynchronously:


  void
  Figure::updateFigureToolBarAndMenuBar (void)
  {
    if (m_mouseModeGroup)
      {
        m_blockUpdates = true;
        m_mouseModeGroup->setMode (mouseMode ());
        m_blockUpdates = false;
      }
  }


and some other thread is presently doing some sort of update for which it has
already set m_blockUpdates to true.  Well, in theory this routine could set
m_blockUpdates "true", finish quickly and then a few machine cycles later set
m_blockUpdates to "false" while the other thread is still working and has not
yet set m_blockUpdates to "false".  So m_blockUpdates would be reset
prematurely and there is a little window of time where m_blockUpdates is
"false" when it really should be "true".  This is why I mentioned "max load". 
When the CPU is chugging away, a "short window of time" becomes a "big window
of time".

Sometimes one can get away with this approach if there is only, say, one
location where m_blockUpdates is set to "false" while maybe multiple places
the variable can be set "true".  Or use a MUTEX to hold off executing these
routines until the data is free to be modified without consequence.  Years ago
I had talked about "comm link" where I prototyped communication between
core/GUI at one finely controlled location--carefully analyzed reference count
modifications and so on to test.  That's a lot of work, and spreading this
throughout the code seems even more difficult.  I've only glanced at this
code, so I don't know what the asynchronous issues are, if any, but I'm just
saying if this is meant to address asynchronous issues, a redesign might be
due.

    _______________________________________________________

Reply to this item at:

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

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