[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: Sat, 14 Apr 2018 13:00:40 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:59.0) Gecko/20100101 Firefox/59.0

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

I agree Pantxo, some fundamental redesign along the lines of hand-shaking of
some sort is needed.  That's not a minor project--or at least not one that can
be done in a week before a release.  Seems like a good summer project, and it
requires coordination between people who know both sides of the threads.

As you mentioned, in this case the asynchronous action is necessary whereas in
other instances it may not be.  Another example of the forced-synchronous
approach is what I did some time ago with the inputdlg() family of routines. 
I forced synchronous timing between interpreter (T2) and GUI (T1) in a really
crude way by putting T2 to sleep while the user is entering data in the
inputdlg.  Once the user closes the modal dialog, T1 will put the data in the
desired location then wake up T2.  So, basically T2 can't do anything when the
inputdlgs are busy.  Crude, but it ensures no thread problems.  There wasn't
much alternative at the time because no design was in place for communication
between the components.  So going forward, if ever Octave GUI-building (i.e.,
one can build their own GUI within Octave...not the "Octave GUI" we commonly
refer to) the inputdlg approach I described is a no-go.  There has to be
active threads on both sides of the divide for something like that.  Just
something to keep in mind.


Reply to this item at:


  Message sent via/by Savannah

reply via email to

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