From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jambunathan K Newsgroups: gmane.emacs.devel Subject: Re: unwind-protect not cleaning up? Date: Sun, 01 Jul 2012 23:17:52 +0530 Message-ID: <81ehovgypj.fsf@gmail.com> References: <814nptaab9.fsf@gmail.com> <87vci97dso.fsf@wanadoo.es> <81bok15psm.fsf@gmail.com> <83bok172m5.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1341164894 15513 80.91.229.3 (1 Jul 2012 17:48:14 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 1 Jul 2012 17:48:14 +0000 (UTC) Cc: ofv@wanadoo.es, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 01 19:48:13 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1SlOFo-0000gL-1Z for ged-emacs-devel@m.gmane.org; Sun, 01 Jul 2012 19:48:12 +0200 Original-Received: from localhost ([::1]:47541 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SlOFn-0006rX-2O for ged-emacs-devel@m.gmane.org; Sun, 01 Jul 2012 13:48:11 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:53482) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SlOFk-0006r3-8T for emacs-devel@gnu.org; Sun, 01 Jul 2012 13:48:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SlOFi-0006rA-6L for emacs-devel@gnu.org; Sun, 01 Jul 2012 13:48:07 -0400 Original-Received: from mail-pz0-f41.google.com ([209.85.210.41]:32987) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SlOFh-0006qs-Tu; Sun, 01 Jul 2012 13:48:06 -0400 Original-Received: by dakp5 with SMTP id p5so7155682dak.0 for ; Sun, 01 Jul 2012 10:48:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=0S64YNOgvLueNIV3ZmumPZw7Ds2mTEPBdFiEXJxKBTw=; b=TSXpg7ydcuxaLQTjNFI2zIHMKziq4n5j6TrJdtnIfO5vWMIQlYb2G61xoIVcLLrUyt 4ibo1A1V2I0jZBtpk9nKYkCs4kHsY80Anz7x1ELabkTrzmrJp+F2Z4+catnEJYDXGpfW l1b8V4ZoTINOBWBGswfdP3PVEueDc2Qv2W16l5xMH8/oGqGdxMTzfCJcPCqXMvFjXqUB yslWNvSt9HjYUTagzrOTCAtqMQxBtBiwQWqUiXZwvLk30sCI3Iywa/XHMaz+SXCca943 dNjwEyFZYOyivoJX5QhJy3N6f9t+kHvqMHmSmsgm0nJP1vReSrL8GtMMsJjbqNZND2ZM fEhA== Original-Received: by 10.68.217.229 with SMTP id pb5mr23412587pbc.19.1341164882032; Sun, 01 Jul 2012 10:48:02 -0700 (PDT) Original-Received: from JAMBU-NETBOOK ([101.63.85.19]) by mx.google.com with ESMTPS id tk1sm10957480pbc.8.2012.07.01.10.47.57 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 01 Jul 2012 10:48:01 -0700 (PDT) In-Reply-To: <83bok172m5.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 30 Jun 2012 09:09:06 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (windows-nt) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.210.41 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:151335 Archived-At: Eli Zaretskii writes: >> From: Jambunathan K >> 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) --