After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 659346 - Handle closing a worksheet during execution
Handle closing a worksheet during execution
Status: RESOLVED FIXED
Product: reinteract
Classification: Other
Component: general
unspecified
Other All
: Normal normal
: ---
Assigned To: reinteract-maint
reinteract-maint
Depends on:
Blocks:
 
 
Reported: 2011-09-17 20:02 UTC by Robert Schroll
Modified: 2011-09-21 01:48 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Handle closing a worksheet during execution (2.83 KB, patch)
2011-09-17 20:02 UTC, Robert Schroll
none Details | Review
If worksheets are still executing on close, show dialog and wait (11.62 KB, patch)
2011-09-21 01:25 UTC, Owen Taylor
committed Details | Review

Description Robert Schroll 2011-09-17 20:02:28 UTC
Right now, a series of Exceptions are raised as Chunks complete 
exectution and try to update the ShellView.  This disconnects those 
signals, allowing the execution to finish up quietly.

Also, the FileList should not change the icon once the file has been
closed.
Comment 1 Robert Schroll 2011-09-17 20:02:30 UTC
Created attachment 196828 [details] [review]
Handle closing a worksheet during execution

We don't want to abort the execution, since that's a bit chancy.
Instead, disconnect the signal handlers that would be called on the
(now gone) ShellView while letting the execution finish.

Also, in FileList, don't update the icon of a closed file.
Comment 2 Owen Taylor 2011-09-21 01:25:02 UTC
Created attachment 197120 [details] [review]
If worksheets are still executing on close, show dialog and wait

Thinking about it, it didn't seem right to me to just leave the worksheet
running in the background - that's not expected by the user - if it vanishes
they will think it's killed.

On the other hand, I didn't want to auto-interrupt - it's a little
untrustworthy in terms of crashing and more untrustworthy in terms of
just stopping the worksheet..

So this patch puts up a dialog with the choice of interrupt or cancel, and
waits until the execution is over or the user cancels. Quite a few details
here in terms of behavior - e.g., we don't want to wait if the user is
closing the only notebook window and we can just exit.

I have some patches that are more complex versions of your disconnection
patch - it turns out that you don't need them for either memory management
(PyGObject manages to hook into Python GC to trace signal connections),
or for this, but they might still be a good idea - for one thing, it's
a lot easier to debug other memory problems when there aren't a lot of
stray signal connections around. I'll attach them to a new bug to sit for a
while to figure if they are useful or not.

===
When a worksheet is still executing when the user tries to close it,
we dont't want to just leave it running, eating CPU and spewing errors,
so if we aren't exiting immediately, show the user a dialog giving
the user the choice to interrupt or cancel.
Comment 3 Owen Taylor 2011-09-21 01:25:44 UTC
Attachment 197120 [details] pushed as b6cd24a - If worksheets are still executing on close, show dialog and wait
Comment 4 Owen Taylor 2011-09-21 01:48:05 UTC
Disconnection patch filed as bug 659653