Re: Race condition seems to be fixed

[Daniel J Sebald]

On 05/21/2012 08:48 AM, Jacob Dawid wrote:
> 2012/5/21 Michael Goffioul<address@hidden>
>
> > On Mon, May 21, 2012 at 1:38 PM, Jacob Dawid<address@hidden>wrote:
> >
> > > Just to clarify: Why do you think the readline callback should be used?
> > > What does it do better?
> >
> > Because that would cover all cases. Readline input hooks are called
> > regularly when octave is idle, whether at normal prompt, or during
> > debugging, or after executing other input hooks, and so on...
> >
> > Michael.
>
> Michael,
>
> I would regard this as an argument against using the readline input hook.
> Comparing and updating the model is an expensive task and we should avoid
> doing it whenever possible.

It sounds like the paradigm you have in mind is the outside app (i.e., 
the GUI) watching large numbers of variables to see if they change. 
This just doesn't sound like the right approach.


>  When I bloat the symbol table with 10000
> variables it takes multiple second to check and rebuild model - you can't
> expect it to run every 0.1s at max. Sure, this is a target for optimization
> (I think of hashing the symbol table before actually comparing it variable
> by variable), but nevertheless we shouldn't stress it I think.

I'm not sure what you mean by hashing.  Is that a fast way of moving 
through a large memory space, e.g., sort of like reverse pointers or 
something?

Anyway, although it may be the case that there are 10,000 variables in 
the environment, it is likely that the app interested in monitoring 
those variables (i.e., the GUI) will only be interested in a limited 
few, up to say 100 at max.  That is to say that the GUI can only display 
100 variables on the screen at once.  So, if there were some way that 
Octave could be told to watch "these select few" variables and notify 
when one of them has changed, maybe that is the best way to always keep 
things in reasonable measure.  If in the GUI the user moves the window 
that watches variables and a completely new set of 100 variables is of 
interest, then indicate to Octave that the existing "watch" or "monitor" 
variables should be tossed in exchange for another set.

I guess it is analogous to the debug feature where Octave is told to 
break at certain lines of code.  Only now it is variable to watch for 
rather than code line.

One tricky thing about the paradigm I suggested is that it may require 
(or not) that Octave can process such a "watch" or "monitor" feature in 
parallel with other processing.  Say for example that the user launches 
a batch process and then clicks the variable window so that a different 
set of variables comes into focus.  Without the ability to change the 
set of monitored variables the new ones that come into scope wouldn't 
change on screen even though they might have in Octave's memory space.

So advantages of that concept:

1) Limited variables to monitor, i.e., efficiency.
2) Octave is doing the bulk of the monitoring and therefore can account 
for some of the other situations where this might be of interest that 
John mentioned.
3) Callback still fits with this so no polling loops.
4) Given that limited variable watch is efficient, could likely add a 
"frequency" option on how often to look at the variables.

Disadvantages:

1) Need to allow changing of monitored variables during Octave's main 
processing.  This could be tricky programming.  It might mean 
multithreads where Octave has a limited scope table.
2) Just exactly how to program this is a big question.  Maybe each 
variable needs a tag of some sort and when it is touched update some 
table that the other thread is watching.  John would be one of the few 
to envision this.  Something similar to debug maybe?

Dan