Re: using timers in the GUI

[Daniel J Sebald]

On 02/18/2013 12:45 PM, Torsten wrote:
> On 18.02.2013 19:03, Jacob Dawid wrote:
> > > Yeah, I don't understand the point of the timer either.  Wouldn't it
> > > be sufficient to just perform the update when the Octave interpreter
> > > is at points where it is safe to perform updates?  For example, in the
> > > readline callback when Octave is waiting for input and perhaps some
> > > other select locations.  Jacob, could you comment about why you chose
> > > to use a timer for this purpose?
> >
> > That's pretty complicated.
> >
> > As far as I recall, the problem was that Qt's model/view mechanism is
> > not - different from what I initially supposed - threadsafe. The
> > updating of the model has to be done from within the Qt thread. As I
> > experienced crashes because of that, I sequenced the access to a
> > specific "intermediate" memory by semaphores (basically just a
> > simplified version of a symbol list). The octave symbol table is queried
> > and the intermediate memory updated whenever the interpreter is ready
> > and the intermediate memory is *not read* by the Qt thread (otherwise it
> > would wait for the Qt thread to finish its job). At times, where the
> > octave interpreter is not accessing the intermediate memory (ie.
> > writing), the Qt thread periodically updates the model based on the
> > intermediate memory. Since there is no guarantee that the procedure
> > invoked by the timer will be finished within an interval, the timer is a
> > single shot timer. It will only fire once, then the timer is restarted
> > by the procedure when the model has been fully updated. That guarantees
> > idle times between updates.
>
> In order to make the updating work within mxe-octave, I changed the
> timer setup with changeset
> http://hg.savannah.gnu.org/hgweb/octave/rev/0486a29d780f
>
> Since the timer can not be started in the callback function, the timer
> was changed into a periodic one and instead, there is a flag for
> enabling and disabling the update. When the timer finishes, the update
> event is fired only if updates are enabled. With firing the event,
> subsequent updates are disabled (by ignoring the timer) and re-enabled
> at the end of the callback function (where the single shot timer was
> restarted by now).
>
> Torsten

Well that's a good solution to that problem.  Yet there is still the 
issue that John and I are wondering about: whether a timer is the way to 
go to update the workspace variable tree.  A couple issues:

1) It is somewhat inefficient to be updating the workspace so often. 
From the code, it appears that the workspace tree is rebuilt every half 
second if Octave is sitting idle at the command line.  If one's 
workspace variables become numerous, not a difficult thing, that could 
be a lot of unnecessary machine cycles.  Being event driven is more 
efficient.

2) The sampling method precludes any possibility for a feature that 
highlights in bold or another color variables which change value between 
the readline and other select locations that John mentions.  What are 
other select locations?  Breakpoints.  Often simulators and emulators 
have the feature I just mentioned, i.e., change the appearance of 
variables that change between two idle moments.  I'm not sure that is a 
feature that some would like to have, but I suspect it might be one of 
those things that until it comes along one doesn't know how much they 
would miss it.

Continuing with item 2, it could be the case such a feature isn't 
possible with the way Octave is currently set up.  I have no idea.  One 
way would be to do a variable-by-variable comparison in the GUI code.  A 
before and after tree, as it were.  Another approach is that if John 
could make the variable table shared memory and include some flag for 
each variable that is changed or added whenever the value of that object 
changes, it might be easier to figure out.  Then again, setting such a 
flag again-and-again within a big loop might be less efficient than just 
doing a before and after variable comparison.  That design element can 
be a future project, but I think that using some method other than a 
timer would be a good change early on.

Dan