Re: Passing variables up to the GUI

[Daniel J Sebald]

On 04/15/2013 01:01 AM, John W. Eaton wrote:
> On 04/14/2013 06:17 PM, Michael Goffioul wrote:
>
> > We can stop the discussion here and agree to disagree. But I believe
> > that passing octave_value objects across threads (through Qt signal/slot
> > or whatever else mechanism) can lead to unpredictable results due to the
> > non-thread-safe nature of refcount management. Once that problem is
> > solved, then I fully agree that all your suggestions make sense: that
> > is, Qt will hold a reference to the passed object until the slot
> > execution is completed, and the emitter can safely discard its own
> > reference.
>
> I'm willing to reconsider enabling atomic refcount by default. But I
> think we should still have an option to disable it. And if it is
> disabled, to also disable the GUI. But I'd like to postpone any decision
> about this until later. My goals right now are to get a working version
> of the GUI release as soon as we can. It doesn't have to be perfect, but
> it has to be reasonably good.
>
> I can see that the octave_link class is not always the most convenient
> thing to do, but it seems to be working. And I'd rather not waste time
> right now arguing about ways to completely redesign the way the GUI
> communicates with the interpreter. That will just delay the release
> more, and I think further delay will be worse than using an imperfect
> method of passing data between the interpreter and the GUI.
>
> So can we please stop arguing about this now?

Just trying to hash things out...

Anyway, the features like modifying data and so on are for down the 
road.  But there is a more immediate concern, which is dbstatus for 
opening a file that has breakpoints in it.  That is a scenario that 
arises pretty easily; just place some breakpoints in a file and close it 
in the editor.  Easy mistake.  If opened the breakpoint info needs to be 
retrieved.

I created a changeset for the scheme I left off with last weekend:

https://savannah.gnu.org/patch/index.php?8016

It uses a QMutex to put the worker thread to sleep while the GUI 
retrieves data from within the octave variables.  The GUI retrieval is 
done very quickly then wakes the worker thread.  I've verified a number 
of things:

1) Passing an octave_value_list across a thread does no dangerous 
copy/delete of octave_value types on two sides of the thread.  But 
copying octave_value by reference does.  Hence, go with octave_value_list.

2) In the case of retrieving data, such as "dbstatus", there is all 
kinds of activity going on with octave_value copy/delete in the GUI 
thread, but since the worker thread is in a wait state, all of that 
activity should be a zero sum.

3) The QMutex setup shouldn't get stuck by, say, getting a wake up 
before going into wait state.  (I'm fairly certain of this point but 
these things are always difficult to test.)  I made sure that before 
waking the worker thread, the QMutex can be locked.  That means that the 
worker thread has reached the wait state and released the QMutex.

I made do_process_events() virtual so it is an easy change, but this 
concept could be brought back one level using std::string and used for 
other types of GUI interfaces.  No callbacks, and breakpoints are 
restored when a file is opened.

Dan