From: Jambunathan K <kjambunathan@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: ofv@wanadoo.es, emacs-devel@gnu.org
Subject: Re: unwind-protect not cleaning up?
Date: Sun, 01 Jul 2012 23:17:52 +0530 [thread overview]
Message-ID: <81ehovgypj.fsf@gmail.com> (raw)
In-Reply-To: <83bok172m5.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 30 Jun 2012 09:09:06 +0300")
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Jambunathan K <kjambunathan@gmail.com>
>> Date: Sat, 30 Jun 2012 11:01:21 +0530
>> Cc: emacs-devel@gnu.org
>>
>> Nothing in the manual suggests that some sort of user-intervention
>> is required for recovery.
>
> Because no intervention is needed, in general. It's just that you
> tried to trigger the stack unwinding with something that signals an
> error and enters the debugger. Change your example to this:
>
> (let ((buffer (get-buffer-create "YOU CANNOT KILL ME")))
> (with-current-buffer buffer
> (let ((eval-expression-debug-on-error nil)
> (debug-on-signal nil))
> (unwind-protect
> (/ 1 0)
> (kill-buffer buffer)))))
>
> and you will get what you expected without any user intervention.
`eval-expression-debug-on-error' and `debug-on-signal' (as used above)
is really too much of an information for a developer who is not working
in Emacs core. Though the above information is useful, it is unlikely
that a Random Joe developer will actually use it. So these need not be
documented.
>> May be I should be looking at someother API that "guarantees" cleanup
>> very much like unwind-protect, without the 'c' part.
>>
>> I can use (condition-case VAR BODYFORM &rest HANDLERS) with the cleanup
>> happening both in BODYFORM and also in (error ) HANDLER. I felt that
>> unwind-protect construct is more elegant. Any suggestions...
>
> The popular use for unwind-protect is when the user could C-g inside
> the protected form. For errors such as division by zero,
> condition-case is indeed better, as you can run some code when the
> error is thrown.
>> Btw, if unwind-protect is behaving the right way, manpage needs an
>> update...
>
> We don't have manpages in Emacs. Did you mean the manual? If so,
> what would you suggest to add/update there, in view of the above?
Here is my recommendation for "(elisp) Cleanups". Re-word it for
correctness or trim it for brevity.
If a (long-running) command allocates resources - processes or buffers -
for it's own work and it needs to be aborted mid-way (remember it is
long-running and the user might lose patience), then one should use an
unwind-protect with cleanup handlers. This way when the user aborts the
command with C-g the command is stopped cleanly.
A command could become long-running against developer's wishes. So
insert a cross-reference to (info "(elisp) Infinite Loops").
We can make the example simpler, with an actual infinite loop as below.
(let ((buffer (get-buffer-create " *temp*")))
(with-current-buffer buffer
(unwind-protect
(while t (ignore)) ;; hog the cpu
(kill-buffer buffer))))
If `debug-on-quit' is nil, then on C-g cleanup forms are executed.
[ADDITIONAL NOTE]
However, if `debug-on-quit' is t, continuing from the debugger with 'c'
will resume the protected form (and cleanup form will not be executed?)
I will also split the "Cleanups" in to two nodes. For want of better
names, let me call it "Cleanup on quit" and "Cleanup on error".
`unwind-protect' will go in the first node and `condition-case' in the
second node. (Manual goes an extra length to clarify that quit and
error are actually two different things.)
[CONTEXT SWITCH]
I also tried comparing `condition-case' with `unwind-protect'.
(condition-case err
(error "Forced error")
((debug error) ;; ASSIGNMENT TO THE READER: add `quit' to this
;; list and see the behaviour on C-g with various
;; values of `debug-on-quit'. Particularly note
;; whether or not the handler is called.
(message "Released resources")))
With `debug' added to the list and `debug-on-error' set to `t', a
developer can examine the stacktrace and also trigger the cleanup with a
`c'. In other words, the cleanup happens irrespective of the value of
`debug-on-error'. (Compare this behaviour with C-g and `debug-on-quit',
search for ADDITIONAL NOTE above)
--
next prev parent reply other threads:[~2012-07-01 17:47 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-30 0:54 unwind-protect not cleaning up? Jambunathan K
2012-06-30 2:07 ` Óscar Fuentes
2012-06-30 5:31 ` Jambunathan K
2012-06-30 6:09 ` Eli Zaretskii
2012-07-01 17:47 ` Jambunathan K [this message]
2012-07-01 18:01 ` Jambunathan K
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=81ehovgypj.fsf@gmail.com \
--to=kjambunathan@gmail.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=ofv@wanadoo.es \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.