Re: integrating QtHandles with Octave

[Daniel J Sebald]

On 01/09/2014 06:46 PM, Michael Goffioul wrote:
> On Thu, Jan 9, 2014 at 3:26 PM, John W. Eaton <address@hidden
> <mailto:address@hidden>> wrote:
>
>     On 01/09/2014 03:06 PM, Michael Goffioul wrote:
>
>         Atomic ref-counting is required for QtHandles, as the GUI runs in a
>         separate thread and accesses graphics objects from there. There is
>         indeed a performance penalty, which is more visible when
>         creating/deleting a lot of objects;
>
>
>     Or copying?  Even though many parts of Octave pass objects that use
>     reference counting by const reference (so no copy) we still have a lot
>     of things that do cause copies to happen (like returning a value from
>     a function).  Any shallow copy that happens is a reference count
>     operation.  Is it slower when using the atomic refcount option?
>
>     Is it possible to avoid the requirement?  Or does that just complicate
>     things too much?
>
>
> It might complicates thing significantly and be memory inefficient:
> you'd to copy the all graphics_object hierarchy to the GUI thread and
> maintain the 2 sets in sync (including during callback execution).
>
> Another possibility is to use a global lock that a thread must acquire
> before using octave objects; the risk there is to get into dead-lock
> situations.

I think the second alternative will actually work.  Since the last time 
this topic came up, I put together a small prototype of such a system 
for the GUI.  The idea was that the GUI asks to do a command in the 
background (e.g., set a value of some variable in response to some GUI 
editing, or request for existing breakpoints in a file upon opening that 
file in the GUI editor) and the Octave worker process executes the 
command and "sends" the result to the GUI along with a tag identifying 
the GUI object that requested the info.  Signals are sent to any object 
that temporarily "registers" itself with possible destinations for some 
data.  By "sending" the data, I really mean a reference (pointer) is 
sent, not the actual data because that would mess with the reference 
count and pose a risk in the thread exchange.  I verified with placement 
of print commands that nothing happens to the reference count under such 
a scenario.

The important detail was that the Octave process must go into a sleep 
state while the GUI (or other) process copies the data locally using the 
reference pointer.  If the main process quickly copies the data then 
wakes the worker process, both processes can then continue--the main 
process probably doing something with the data it just copied.  The 
mechanism to handle this is the Mutex.  There is a mode whereby the 
worker process (Octave) locks the mutex and then goes into a sleep 
state, and upon going into that sleep state the process gives up its 
lock so that some other process can take over.  When the mutex is done 
with, the work process awakes (with the lock, I think).

That's what I recall anyway,

Dan