[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Should `cancel-timer' use `delete' instead of `delq'?

From: Drew Adams
Subject: RE: Should `cancel-timer' use `delete' instead of `delq'?
Date: Tue, 5 Sep 2006 19:09:11 -0700

    > 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

    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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]