octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Passing variables up to the GUI


From: Michael Goffioul
Subject: Re: Passing variables up to the GUI
Date: Sat, 13 Apr 2013 11:52:46 -0400

On Fri, Apr 12, 2013 at 11:55 PM, Daniel J Sebald <address@hidden> wrote:
On 04/12/2013 10:37 PM, John W. Eaton wrote:
On 04/12/2013 11:32 PM, Daniel J Sebald wrote:
On 04/12/2013 10:14 PM, Daniel J Sebald wrote:

On the GUI side and interface, there is a bit more work. I suppose there
would need to be two queues, maybe one for the user input commands, and
one for the "callback" commands. The GUI needs to queue up the command
and also what object wants the data. The object that wants the data has
to know what it asked for and how to interpret it. Maybe it asks for
"x". Or maybe it asks for "size(x)". Or maybe "x(1:10,21:30)".

Followup thought. Maybe the thing to do is instead of attempting the
"corefeval" function first, is to just create some octave_value object
on the core side, say a small matrix, and see if that can be sent over
by reference using

emit octave_result (qobject, ovres);

to some hunk of code on the GUI side that will just toss up a dialog
showing the contents of the object.

I predict crashes because of reference counting operations that are not
thread safe.

Eh, we'll see.

Trust me, it'll crash. I've tried that in QtHandles and that's the reason I implemented atomic refcount in octave.
 
 Octave is running in a QThread, so Qt's scheme is the one influencing garbage collection.

I'm not sure what you refer to with "garbage collection", we're talking about C++ here. And Qt is completely unaware of the octave-internal reference counting.
 
 Documentation says that the slots are all processed immediately upon a signal so once that is all done, the reference can be discarded.

That is, if the QObject receiver lives in the same thread that fires the signal. Otherwise, the default is to queue the signal in the eventloop of the thread owning the QObject (and for that to work, the target thread must have a running eventloop). You can change that behavior and make the signal emission blocking, but then you've the problem of deadlocking your threads (something I also experienced in QtHandles).

Michael.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]