[Octave-bug-tracker] [bug #58403] "uicontextmenu" property is not empty immediately after deleting corresponding graphics object

[Pantxo Diribarne]

Follow-up Comment #1, bug #58403 (project octave):

The current workflow is as follows: 
1- uicontextmenu object deletion requested
2- notify the gui thread that it should delete the ContextMenu object and
release its reference to the uicontexmenu. Block the interpreter thread until
it's done.
3- delete the last reference to the uicontextmenu held by the gh_manager.
4- handle the uicontextmenu property in the uicontextmenu destructor

But if step 2 fails, the destructor won't get called in time (at all?)

I tried hard to use Qt's blocking connections to have predictable behavior,
but it doesn't look like the correct approach: sometimes invokeMethod will
fail to execute the requested slot and your only choice is to try again (and
implement  your own local ugly blocking connection).


The attached patch will probably help in reducing the probability that this
bug happens but is a fig leaf.  
This BlockingQueuedConnection method has improved stability, but turns out to
be very slow and is still unpredictable. 





(file #49150)
    _______________________________________________________

Additional Item Attachment:

File name: bug58403.patch                 Size:1 KB
    <https://savannah.gnu.org/file/bug58403.patch?file_id=49150>



    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Message posté via Savannah
  https://savannah.gnu.org/