segfaults in graphics code (likely threading issues?)

[John W. Eaton]

We have two bug reports about random crashes during the build or when 
running the tests:

  https://savannah.gnu.org/bugs/?57591
  https://savannah.gnu.org/bugs/?56952

The crashes usually happen when executing some graphics code and my 
guess is that they are all related to threading issues with the Qt 
graphics toolkit.

We manage the graphics handle data in libinterp/corefcn/graphics.{h,cc} 
and the Qt code is in the libgui/graphics directory.  The Qt graphics 
display runs in the GUI thread, separate from the thread where the 
interpreter runs.  To safely access data from one thread in the other, 
we need some kind of thread safe queue or locking.  Currently, I think 
all we are doing is using some fairly coarse locking on the gh_manager 
object.  Is that sufficient?  Are there cases where we lock to obtain a 
graphics_object in the GUI thread but then unlock while still using the 
object?

There are also some questionable calls to unlock the mutex.  For 
example, in qt_graphics_toolkit::initialize and 
qt_graphics_toolkit::finalize, I see

        // FIXME: We need to unlock the mutex here but we have no way 
to know if
        // if it was previously locked by this thread, and thus if we 
should
        // re-lock it.

        gh_manager& gh_mgr = m_interpreter.get_gh_manager ();

        gh_mgr.unlock ();

Even if that is not the cause of the trouble, it seems worth 
eliminating.  It seems to me that locks should be managed automatically 
based on scope, not explicitly unlocked in functions separate from where 
they are initially locked.

Is there a better way to pass data between the separate interpreter and 
graphics toolkit threads?  Can we simply lock a mutex in graphics_object 
methods so that we can safely access them in multiple threads?  Or do we 
need a whole new way of passing data between the interpreter and the 
graphics toolkit?

jwe