Re: Race condition seems to be fixed

[John W. Eaton]

On 21-May-2012, Jacob Dawid wrote:

| There is an ugly thing about that: What I did previously was to open
| a separate thread that was polling the symbol table in octave. Now
| the GUI model only gets updated when octave thinks it is worth to do
| that. We can discuss whether we can reduce this somehow, but as it
| is right now feels kind of "snappy" to me.  Anyways, I like the idea
| of octave deciding whether to update or not.
| 
|     Regarding your proposal, as John said, it's not generic enough. For
|     instance you're missing any executed readline input hooks. This is
|     typically used in the backends to execute handlers. This design looks very
|     similar to what was done in OctaveDE. At this point, I think your best bet
|     would be to install your own readline input hook. Ideally, this hook 
should
|     be as light as possible (when there's nothing to be done) to avoid octave
|     consuming CPU in idle state.
|    
|     Michael.
| 
| Let's see how that works out, okay? We can still improve on that or remove it
| if it is bad.

There are other places where the symbol table could change.  For
example, the loop in eval_string in oct-parse.yy, which is similar to
the one in main_loop in toplev.cc and the one in get_debug_input in
input.cc.  Command history can also change in get_debug_input, though
I don't think it should be changing in eval_string.

And, as Michael mentions, if Octave code is executing in the readline
idle loop, then it is possible that the symbol table will change
there, but I'm not sure how often that happens in practice, since most
callbacks that are executing there are functions, correct?  Is it
typical for them to change the top-level symbol table (which is what I
assume is usually displayed in the IDE)?

jwe