Re: Eliminating Singleton Objects (Re: Coloring error and warning messages in the gui console)

[Daniel J Sebald]

On 05/18/2017 03:50 PM, John W. Eaton wrote:
> On 05/09/2017 04:13 PM, Daniel J Sebald wrote:
>
> > For
> > example, intermixing of GUI and core/interpreter is unnecessary, as I
> > feel there is a wealth of built-in commands that offer up all the
> > information the GUI needs, if only there were a simple routine to return
> > the result of an interpreter command (which can be done across a thread
> > by passing a pointer to an octave_value_list rather than a reference to
> > an octave_value_list).
>
> I don't see how a reference is different from a pointer for that
> purpose.  Can you explain?

My recollection is that it's different.  Mike Miller may have pointed 
out the problem with reference counting across the thread, so I dug into 
just what it is that Qt is doing when queuing signals (at the time I 
built the latest Qt so I could print out some debugging info deep in the 
signal/slot mechanism).  I can't recall exactly, but I'll try to explain 
from what I remember.

So my thought on any mechanism that communicates data across the thread 
is that the GUI should think of the core as a resource and not hog that 
resource by doing graphics-related activity when the core is 
communicating it's function result.  For example, don't do plotting or 
complicated table-updates, etc. while the core is frozen waiting for an 
acknowledgement that the octave_value_list result is no longer needed. 
That means quickly copying the data on the GUI thread, then free the 
interpreter thread, then do the time-consuming graphical items.

That copying of the data, I believe is what the issue is.  I think that 
when a reference was passed over, when the GUI copied the data as a 
reference, it increased that object's reference count by 1.  How to undo 
that from the GUI side, once the core is acting independently again 
(i.e., not frozen waiting on the GUI), I don't know.  Maybe a system 
allowing reference counting in and across both threads can be done, but 
I thought it better to only let the GUI make immediate copies of data 
and that is all.  Otherwise, maintenance might get too complicated. 
Stated differently, I think it best if only core in its one thread deal 
with reference counting.

In any case, when I reconfigured that communication to use the 
octave_value_list pointer rather than the reference, copying via pointer 
did not affect the reference count.  At the time of this GUI copy, the 
core was frozen in a sleep state, so that the data can't disappear and 
result in a segmentation fault.  From the core's standpoint, once the 
GUI wakes it again, it's as if nothing changed.

Dan