[Octave-bug-tracker] [bug #44485] GUI: File | Exit from main menu doesn't work when Octave is busy

[Dan Sebald]

Follow-up Comment #29, bug #44485 (project octave):

Here's a patch that I think is very near to what I've envisioned the closing
process should be like.  It is a considerable rearrangement of the closing
code which relies more on the connections of signals and slots.  The
connections sort of act like a linked-list or serial processing of editor
tabs.  One tab's save-continue signal is connected to the next tab's
save-confirm slot.  If there is a cancellation, the tab doesn't emit the
signal.

The proposed setup has more flexibility to shape the behavior of dialog boxes
when closing and preventing things like a dialog opening multiple times.  So
if there are any changes to be made, only small tweaks should be necessary.

Also, I did come across the long, verbose error message that I think you are
seeing.  I'm not 100% certain, but I sort of isolated the cause as being
related to the Qt Handles code.  If the interpreter thread is terminated, the
message originates after the termination.  I think there is some kind of
coordination going on between the interpreter and Qt Handles that is
compromised when the interpreter quits prematurely.  I'd rather not dig into
the Qt Handles code--at least not initially.  Judging from bug reports, there
are certain parts of Qt use that aren't as robust as others and I suspect
there will be changes somewhere in the future.  Nonetheless, the new scheme is
set up so that terminating the interpreter is the last resort and the error
message shouldn't appear so often if at all.

Here's a summary of changes:

1) Selecting "quit" or the upper-right close button will place an "exit" in
the queue, as before.

2) A timer expires after 2 seconds if no shutdown is requested by the core and
a dialog box is shown inquiring about "force exit", as before.

3) The existence of signal/slot connections determines if a dialog box is
already present so that only one "force exit" dialog exists at a time.  (I.e.,
can no longer select "quit" twice quickly to create two dialog boxes asking to
force quit.)

4) If the user selects force quit, the confirm-save process is started.  If
that confirm-save process is complete before the interpreter asks to shutdown,
the force-exit route is taken.

5) The force-exit route will issue a Cntrl-C, place "exit" in the queue again,
and wait 0.5 seconds for a response.  Typically, in this scenario the
interpreter will ask to shutdown at this point and another confirm-save will
NOT be done.  Also, this is a clean exit so no error messages should appear.

6) If 5 still doesn't exit, that's an indication of the core really
stuck/lost.  After half a second, the 3 Cntrl-C approach is attempted followed
by terminating the interpreter.  This is a sort of last effort type of thing. 
Here's when the error message might occur and if someone files a bug report
for this I will look at the Qt Handles code.

7) And one last detail, if the user does a force-exit and is in the process of
saving editor tabs when/if the interpreter gets around to requesting shutdown,
the signal of completion is disconnected and reconnected instead to a slot
that is the conventional response.  That makes sure that save-confirm isn't
run twice simultaneously.


(file #34183)
    _______________________________________________________

Additional Item Attachment:

File name: octave-exit_timer-djs2015jun08.patch Size:29 KB


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?44485>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/