|
From: | John Swensen |
Subject: | Re: Threadsafe octave patch |
Date: | Mon, 20 Nov 2006 20:05:17 -0500 |
User-agent: | Thunderbird 2.0a1 (X11/20060807) |
John W. Eaton wrote:
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?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
John
[Prev in Thread] | Current Thread | [Next in Thread] |