[Octave-bug-tracker] [bug #65797] adding keyboard command within __bar__.m update_data() function causes Octave hang

[John W. Eaton]

Follow-up Comment #1, bug #65797 (group octave):

As far as I can tell, this problem happens because of the poor design of the
gh_manager class.  I see the main GUI thread blocked at the point that it is
attempting to lock the mutex for the gh_manager object.  Then I also see that
the interpreter thread is waiting for input, but that doesn't work with the
GUI because the main GUI thread appears to be waiting to acquire the mutex.

Instead of this pattern that we are currently using:

* lock the gh_manager object
* do some graphics things - might be many things that affect the state of many
graphics objects and properties
* unlock the gh_manager object

we should only be locking the gh_manager object when we make individual
modifications (get or set, primarily).  Each of those operations should be
fast and should never call any other functions that need to lock the
gh_manager object.

It seems to me that the mutex and all locking should be internal to the
gh_manager object.  We should not be able to get a reference to the graphics
objects and their properties that are managed by the gh_manager class and then
modify the contents of those graphics objects directly.  Instead, we should
only be able to create, delete, modify, or perform other operations through
individual thread-safe functions that only need to do local, limited locking.

Fixing this is a fairly big job but I think it needs to be done, not just to
fix this bug, but to avoid other mysterious hangs and/or crashes that could
happen with the current design.

We might also use a design similar to the QSettings class to provide
thread-safe access to the global gh_manager object itself.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65797>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/