[Top][All Lists]

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

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

From: Dan Sebald
Subject: [Octave-bug-tracker] [bug #53513] graphics.cc-tst FAIL
Date: Tue, 10 Apr 2018 12:10:01 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0

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)

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:

  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


Reply to this item at:


  Message sent via/by Savannah

reply via email to

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