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

[Miles Bader]

"Drew Adams" <address@hidden> writes:
> I was able to be bitten by it, using C-M-x on the defvar.

That's a good point, but it's also a very special case -- if you're
using a debugging command to _force_ a construct to act in an abnormal
manner, you presumably know what your doing.

> And the general point applies to setq as well.

But I think the answer is not a macro, because there's an obvious, simple, and
extremely widespread idiom for dealing with this situation, which every
programmer should know about (if they don't, they're unlikely to realize they
should be using the special macro):

   (if var (free-non-gced-thing var))
   (setq var (make-non-gced-thing))

Not exactly rocket science...

> 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.

Er, there _is_ such a function already:  `timer-create'.

But anyway, that doesn't help: the problem is when code "forgets" about
about an activated timer.  If you do (setq my-timer (timer-create)), and
the old value of my-timer was an activated timer, you're going to leak
the old timer even though the new timer is not activated.

>     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 ;-).

   static char *buf = 0;

   void init_my_package ()
   {
           buf = malloc (100);
           ...
   }

Whoops!

> 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.

Huh?  It doesn't seem reasonable or natural at all.  Activated timers
have an externally visible effect, so clearly they can't simply "go
away."

Someone writing code using timers needs to know this.

-miles

-- 
Come now, if we were really planning to harm you, would we be waiting here,
 beside the path, in the very darkest part of the forest?