Re: Octave GUI: QtHandles and Race Conditions

[Michael Goffioul]

On Fri, May 4, 2012 at 9:05 PM, Jacob Dawid <address@hidden> wrote:
> Hello everyone,
>
> I have been discussing the issues that we can solve within GSoC with Jordi.
> Now we think there are two major points to solve first: Integration of Qt
> Handles to have the same GUI Toolkit for rendering graphs like we have for
> the GUI and fixing the race conditions.
>
> So, basically, there are two big questions:
>
> 1.) How difficult would it be to integrate QtHandles? What work needs to be
> done to have this working?

It depends on the level of integration. QtHandles is pretty
independent of the GUI, and it can hook into an existing QApplication
automatically. It's using qmake for building. So it we're only talking
about copying the source code and integrating into GUI build system,
it should be trivial.

One thing though that is missing in order to have something 100%
equivalent to the FLTK toolkit, is to add support for printing.
Obviously, a large part of the code used for FLTK can be re-used.

> 2.) How could we fix the race conditions with refcounting? Why does atomic
> refcounting not help? An idea that I came up with was to introduce a
> callback function in which the GUI code has the opportunity to safely read
> variables.

My first impression is that is must be due to an unsafe use of
reference counter somewhere in the symbol table code. When
implementing atomic refcount, I've tested it extensively with
QtHandles (which runs in its own thread). While I could make it crash
pretty easily without atomic refcount, all these problems disappeared
when I added atomic refcount.

However, QtHandles mainly uses the graphics system, so that's where I
put most of the efforts. I didn't audit the symbol table code for
potential unsafe behavior. That's where I would start. Also, did you
try to reproduce the problem with valgrind?

Michael.