From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: Should `cancel-timer' use `delete' instead of `delq'? Date: Tue, 5 Sep 2006 19:09:11 -0700 Message-ID: References: <87k64hiysj.fsf@catnip.gol.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1157508572 12214 80.91.229.2 (6 Sep 2006 02:09:32 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 6 Sep 2006 02:09:32 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 06 04:09:30 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1GKmr3-0004Tn-Gn for ged-emacs-devel@m.gmane.org; Wed, 06 Sep 2006 04:09:29 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GKmr2-00007N-V1 for ged-emacs-devel@m.gmane.org; Tue, 05 Sep 2006 22:09:28 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GKmqs-00007I-2v for emacs-devel@gnu.org; Tue, 05 Sep 2006 22:09:18 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GKmqp-00005t-HE for emacs-devel@gnu.org; Tue, 05 Sep 2006 22:09:16 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GKmqp-00005g-E9 for emacs-devel@gnu.org; Tue, 05 Sep 2006 22:09:15 -0400 Original-Received: from [141.146.126.228] (helo=agminet01.oracle.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.52) id 1GKmqs-0004IU-AY for emacs-devel@gnu.org; Tue, 05 Sep 2006 22:09:18 -0400 Original-Received: from rgmsgw02.us.oracle.com (rgmsgw02.us.oracle.com [138.1.186.52]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k8629DIB021762 for ; Tue, 5 Sep 2006 21:09:13 -0500 Original-Received: from dradamslap (dhcp-amer-whq-csvpn-gw3-141-144-81-61.vpn.oracle.com [141.144.81.61]) by rgmsgw02.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id k8629CId030944 for ; Tue, 5 Sep 2006 20:09:13 -0600 Original-To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <87k64hiysj.fsf@catnip.gol.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:59408 Archived-At: > To repeat my question: Is it a good idea to either document the > "traditional" `define-minor-mode' approach or define a new > macro for this, or should we just let people discover this on their own? I think the macro is inappropriate; the problem generally doesn't occur in typical "define" contexts (for instance your defvar "protection" will never get executed, because of the way defvar works). I was able to be bitten by it, using C-M-x on the defvar. And the general point applies to setq as well. I'd guess that most "define" contexts are not intended to create multiple timers if for any reason they happen to get re-evaluated. And I'd guess that most people creating those contexts will never even consider the potential problem. I doubt that more than 1% of them have even heard of the "traditional" `define-minor-mode' way of defining timers. How many of them will be bit by this? Who knows? Why not help them avoid it? If this is actually a problem in practice, just documenting it seems good enough. Documenting it is a good start. To me, it makes sense to have a construct for defining a timer, which doesn't also automatically activate it. Why not separate the two acts, as we do (by default) with advice? As it stands now, to create a timer that is not activated, you must create-and-activate it, and then cancel it. Is this potential problem really any more widespread than millions of other very similar bugs though? This is exactly the same as many other sorts of resource allocation/deallocation; Show us the millions of other very similar bugs, and we can compare ;-). we don't explicitly warn people about each of them because we assume than programmers know how to handle this sort of thing in general. You assume too much, I think. If I defvar or setq toto to (cons 1 2)), and I make no other assignments or bindings to that cons cell, and then I setq toto to (cons 3 4), should I assume that the first cons cell is still around causing mischief? Maybe, for a while. I think that one natural, if erroneous, expectation is that the orphan timer will naturally go by the wayside at some point, and need not be thought much about. There are other, just as natural, expectations that would be more correct, but that expectation is a possible and reasonable one: don't worry about that zombie timer; it's history; it may be toast already.