Re: Threadsafe octave patch

[John Swensen]

John W. Eaton wrote:
> On  9-Nov-2006, John Swensen wrote:
>
> | The attached patch is my first attempt at creating a threadsafe 
> | mechanism for my IDE to access octave internals.  Currently the 
> | following functionalities are implemented:
> | 1) List of variables in scope with name, type, size, etc.
> | 2) Ability to request full variables
> | 3) Request history information
> | 
> | Planned functionality:
> | Set/clear/step in/step out for breakpoints
> | Allow this to be turned on and off
> | 
> | Please let me know if this is an acceptable solution or if there are 
> | changes you would like me to make before it would be accepted.
>
> Wouldn't it be better for the IDE to be able to ask Octave for the
> information it needs (anything, not just a selected subset of the
> internal state) or call any Octave function?
>
> jwe
>
>   
Sure! That would be much better.  Now I need a little help determining 
the locations in the code to "lock" Octave.  Clearly the "unlock" should 
occur at the end of the while loop in main_loop() of toplevel.cc and in 
MAYBE_DO_BREAKPOINT in pt-bp.h.  Is there a point after the readline 
command has been entered, but before any actual octave code is 
interpreted?  I think this would be the place to "lock" octave back up.  
Then the IDE would do a "pthread_mutex_trylock" and if it fails, simply 
try again later.  This way, *all* the normal octave functions will work, 
rather than having me try to implement a bunch of wrappers.  Could 
someone suggest where to look for the best post-readline/pre-interpret 
location for this mutex lock?  Are there any other places where a 
lock/unlock needs to occur?

John