* Timer scheduling and cancel-timer
@ 2013-01-20 15:58 Tomohiro Matsuyama
2013-01-20 19:22 ` Paul Eggert
0 siblings, 1 reply; 22+ messages in thread
From: Tomohiro Matsuyama @ 2013-01-20 15:58 UTC (permalink / raw)
To: emacs-devel
Hi,
I have found a problem that cancel-timer will not work in a particular
situation where the timer takes more time to execute than a
rescheduling interval of the timer. Here is the reproducible code:
(setq my-timer
(run-with-timer
nil 0.1
(lambda ()
(when my-timer
(cancel-timer my-timer)
(setq my-timer nil)
(sit-for 0.3)))))
After evaluating this code several times, you may see "zombie" timers
in timer-list, though the code intends to keep at most one timer.
As my quick look, the problem may be caused by timer_check in
keyboard.c by firing the timer twice at the same time, that makes the
timer remain in timer-list though the timer has been canceled.
Regards,
Tomohiro
--
Tomohiro Matsuyama <tomo@cx4a.org>
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Timer scheduling and cancel-timer
2013-01-20 15:58 Timer scheduling and cancel-timer Tomohiro Matsuyama
@ 2013-01-20 19:22 ` Paul Eggert
2013-01-20 21:04 ` Drew Adams
2013-03-31 11:17 ` Tomohiro Matsuyama
0 siblings, 2 replies; 22+ messages in thread
From: Paul Eggert @ 2013-01-20 19:22 UTC (permalink / raw)
To: Tomohiro Matsuyama; +Cc: emacs-devel
On 01/20/2013 07:58 AM, Tomohiro Matsuyama wrote:
> (setq my-timer
> (run-with-timer
> nil 0.1
> (lambda ()
> (when my-timer
> (cancel-timer my-timer)
> (setq my-timer nil)
> (sit-for 0.3)))))
>
> After evaluating this code several times, you may see "zombie" timers
> in timer-list, though the code intends to keep at most one timer.
Hmm, isn't that due to a race in the above code?
A timer can fire when a timer action is running.
Do you get zombie timers with the following?
It should avoid the race.
(setq my-timer
(run-with-timer
nil 0.1
(lambda ()
(let ((m my-timer))
(when m
(cancel-timer m)
(setq my-timer nil)
(sit-for 0.3))))))
^ permalink raw reply [flat|nested] 22+ messages in thread
* RE: Timer scheduling and cancel-timer
2013-01-20 19:22 ` Paul Eggert
@ 2013-01-20 21:04 ` Drew Adams
2013-01-20 21:35 ` Drew Adams
2013-01-21 1:36 ` Stefan Monnier
2013-03-31 11:17 ` Tomohiro Matsuyama
1 sibling, 2 replies; 22+ messages in thread
From: Drew Adams @ 2013-01-20 21:04 UTC (permalink / raw)
To: 'Paul Eggert', 'Tomohiro Matsuyama'; +Cc: emacs-devel
I have no idea whether this is relevant, but I'll mention it, as it might be.
I have used Francis Wright's library `dired-sort-menu.el' for years. Yesterday,
with a build from 2013-01-18, I somehow got in a situation where this kept
happening:
Debugger entered--Lisp error: (wrong-type-argument integer-or-marker-p t)
#[nil ...
ad-Advice-show-paren-function(#[nil...
show-paren-function()
apply(show-paren-function nil)
#[nil ... [timer apply 5 6] 4]()
timer-event-handler([t 0 0 125000 t show-paren-function nil idle 0])
It happened over and over and over: as soon as I quit the debugger it popped up
again. `dired-sort-menu.el' has this defadvice, which is apparently the one
involved here:
(defadvice show-paren-function (around show-paren-function-advice activate)
"Do not show matching parens in a dired sort dialogue buffer."
(or (dired-sort-dialogue-buffer-p (buffer-name)) ad-do-it))
I was able to quit the Emacs session, and I have not seen the problem since,
even with the same build.
Again, dunno whether this is related to your discussion. Ignore if not.
^ permalink raw reply [flat|nested] 22+ messages in thread
* RE: Timer scheduling and cancel-timer
2013-01-20 21:04 ` Drew Adams
@ 2013-01-20 21:35 ` Drew Adams
2013-01-21 1:36 ` Stefan Monnier
1 sibling, 0 replies; 22+ messages in thread
From: Drew Adams @ 2013-01-20 21:35 UTC (permalink / raw)
To: 'Paul Eggert', 'Tomohiro Matsuyama'; +Cc: emacs-devel
> I was able to quit the Emacs session, and I have not seen the
> problem since, even with the same build.
FWIW, it just happened again (different session, same build).
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Timer scheduling and cancel-timer
2013-01-20 21:04 ` Drew Adams
2013-01-20 21:35 ` Drew Adams
@ 2013-01-21 1:36 ` Stefan Monnier
2013-01-21 1:39 ` Drew Adams
1 sibling, 1 reply; 22+ messages in thread
From: Stefan Monnier @ 2013-01-21 1:36 UTC (permalink / raw)
To: Drew Adams
Cc: 'Tomohiro Matsuyama', 'Paul Eggert', emacs-devel
> I have no idea whether this is relevant, but I'll mention it, as it might be.
Sounds unrelated.
> Debugger entered--Lisp error: (wrong-type-argument integer-or-marker-p t)
> #[nil ...
> ad-Advice-show-paren-function(#[nil...
> show-paren-function()
> apply(show-paren-function nil)
> #[nil ... [timer apply 5 6] 4]()
> timer-event-handler([t 0 0 125000 t show-paren-function nil idle 0])
Until recently timer-event-handler just silently dropped all errors
signaled by timers, whereas I recently changed it to turn them into
messages (a nd to show the backtrace if debug-on-error is non-nil).
So maybe this error has been present for ever but just got unnoticed
until now. The "#[nil ...]" seems to be the unadvised body of
show-paren-function, so the error apparently comes from within
show-paren-function.
Stefan
^ permalink raw reply [flat|nested] 22+ messages in thread
* RE: Timer scheduling and cancel-timer
2013-01-21 1:36 ` Stefan Monnier
@ 2013-01-21 1:39 ` Drew Adams
2013-01-22 3:50 ` Drew Adams
0 siblings, 1 reply; 22+ messages in thread
From: Drew Adams @ 2013-01-21 1:39 UTC (permalink / raw)
To: 'Stefan Monnier'
Cc: 'Tomohiro Matsuyama', 'Paul Eggert', emacs-devel
> > I have no idea whether this is relevant, but I'll mention
> > it, as it might be.
>
> Sounds unrelated.
>
> > Debugger entered--Lisp error: (wrong-type-argument
> > integer-or-marker-p t)
> > #[nil ...
> > ad-Advice-show-paren-function(#[nil...
> > show-paren-function()
> > apply(show-paren-function nil)
> > #[nil ... [timer apply 5 6] 4]()
> > timer-event-handler([t 0 0 125000 t show-paren-function
> > nil idle 0])
>
> Until recently timer-event-handler just silently dropped all errors
> signaled by timers, whereas I recently changed it to turn them into
> messages (a nd to show the backtrace if debug-on-error is non-nil).
>
> So maybe this error has been present for ever but just got unnoticed
> until now. The "#[nil ...]" seems to be the unadvised body of
> show-paren-function, so the error apparently comes from within
> show-paren-function.
I see. Since this happened for the first time yesterday, and it happened once
today, I thought it might be related, but your explanation makes sense also. I
was using a build from 12/31 until 1/18, so if you made your change during that
period that too would explain why I see the problem for the first time now.
^ permalink raw reply [flat|nested] 22+ messages in thread
* RE: Timer scheduling and cancel-timer
2013-01-21 1:39 ` Drew Adams
@ 2013-01-22 3:50 ` Drew Adams
2013-01-22 11:28 ` Stephen Berman
2013-01-22 13:34 ` Stefan Monnier
0 siblings, 2 replies; 22+ messages in thread
From: Drew Adams @ 2013-01-22 3:50 UTC (permalink / raw)
To: 'Stefan Monnier'
Cc: 'Tomohiro Matsuyama', 'Paul Eggert', emacs-devel
> It happened over and over and over: as soon as I quit the debugger
> it popped up again.
>
> > Until recently timer-event-handler just silently dropped all errors
> > signaled by timers, whereas I recently changed it to turn them into
> > messages (a nd to show the backtrace if debug-on-error is non-nil).
> >
> > So maybe this error has been present for ever but just got unnoticed
> > until now. The "#[nil ...]" seems to be the unadvised body of
> > show-paren-function, so the error apparently comes from within
> > show-paren-function.
FWIW, I have been treated to this infinitely repeating backtrace several times
now.
Perhaps it is worth reverting the code change you made that makes this happen
now, until you find the bug?
I'm kind of surprised that no one else seems to be running into this problem.
Each time it arises, point follows a right paren, I believe.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Timer scheduling and cancel-timer
2013-01-22 3:50 ` Drew Adams
@ 2013-01-22 11:28 ` Stephen Berman
2013-01-22 16:00 ` Stephen Berman
2013-01-22 13:34 ` Stefan Monnier
1 sibling, 1 reply; 22+ messages in thread
From: Stephen Berman @ 2013-01-22 11:28 UTC (permalink / raw)
To: Drew Adams
Cc: 'Tomohiro Matsuyama', 'Paul Eggert',
'Stefan Monnier', emacs-devel
On Mon, 21 Jan 2013 19:50:44 -0800 "Drew Adams" <drew.adams@oracle.com> wrote:
>> It happened over and over and over: as soon as I quit the debugger
>> it popped up again.
>>
>> > Until recently timer-event-handler just silently dropped all errors
>> > signaled by timers, whereas I recently changed it to turn them into
>> > messages (a nd to show the backtrace if debug-on-error is non-nil).
>> >
>> > So maybe this error has been present for ever but just got unnoticed
>> > until now. The "#[nil ...]" seems to be the unadvised body of
>> > show-paren-function, so the error apparently comes from within
>> > show-paren-function.
>
> FWIW, I have been treated to this infinitely repeating backtrace several times
> now.
>
> Perhaps it is worth reverting the code change you made that makes this happen
> now, until you find the bug?
>
> I'm kind of surprised that no one else seems to be running into this problem.
> Each time it arises, point follows a right paren, I believe.
I hit it several times after updating from the trunk on 17 January but
didn't have time to try to debug it, and also couldn't find a reliable
recipe for reproducing it. Anyway, for whatever reason, I haven't seen
it again for a couple of days (with the same build).
Steve Berman
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Timer scheduling and cancel-timer
2013-01-22 3:50 ` Drew Adams
2013-01-22 11:28 ` Stephen Berman
@ 2013-01-22 13:34 ` Stefan Monnier
2013-01-22 13:57 ` Bastien
1 sibling, 1 reply; 22+ messages in thread
From: Stefan Monnier @ 2013-01-22 13:34 UTC (permalink / raw)
To: Drew Adams
Cc: 'Tomohiro Matsuyama', 'Paul Eggert', emacs-devel
> Perhaps it is worth reverting the code change you made that makes this happen
> now, until you find the bug?
No, the change is there specifically to avoid hiding bugs under the rug.
> Each time it arises, point follows a right paren, I believe.
If you hit C-M-x in the definition of show-paren-function, the backtrace
might prove more instructive.
Stefan
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Timer scheduling and cancel-timer
2013-01-22 13:34 ` Stefan Monnier
@ 2013-01-22 13:57 ` Bastien
2013-01-22 14:14 ` Stefan Monnier
0 siblings, 1 reply; 22+ messages in thread
From: Bastien @ 2013-01-22 13:57 UTC (permalink / raw)
To: Stefan Monnier
Cc: 'Tomohiro Matsuyama', 'Paul Eggert', Drew Adams,
emacs-devel
[-- Attachment #1: Type: text/plain, Size: 305 bytes --]
Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
>> Perhaps it is worth reverting the code change you made that makes this happen
>> now, until you find the bug?
>
> No, the change is there specifically to avoid hiding bugs under the
> rug.
The attached patch fixes the bug.
Can anyone confirm this?
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: paren.el.patch --]
[-- Type: text/x-patch, Size: 1585 bytes --]
=== modified file 'lisp/paren.el'
--- lisp/paren.el 2013-01-01 09:11:05 +0000
+++ lisp/paren.el 2013-01-22 13:55:42 +0000
@@ -243,23 +243,23 @@
;;
;; Turn on highlighting for the matching paren, if found.
;; If it's an unmatched paren, turn off any such highlighting.
- (unless (integerp pos)
- (delete-overlay show-paren-overlay))
- (let ((to (if (or (eq show-paren-style 'expression)
- (and (eq show-paren-style 'mixed)
- (not (pos-visible-in-window-p pos))))
- (point)
- pos))
- (from (if (or (eq show-paren-style 'expression)
+ (if (not (integerp pos))
+ (when show-paren-overlay (delete-overlay show-paren-overlay))
+ (let ((to (if (or (eq show-paren-style 'expression)
(and (eq show-paren-style 'mixed)
(not (pos-visible-in-window-p pos))))
- pos
- (save-excursion
- (goto-char pos)
- (- (point) dir)))))
- (if show-paren-overlay
- (move-overlay show-paren-overlay from to (current-buffer))
- (setq show-paren-overlay (make-overlay from to nil t))))
+ (point)
+ pos))
+ (from (if (or (eq show-paren-style 'expression)
+ (and (eq show-paren-style 'mixed)
+ (not (pos-visible-in-window-p pos))))
+ pos
+ (save-excursion
+ (goto-char pos)
+ (- (point) dir)))))
+ (if show-paren-overlay
+ (move-overlay show-paren-overlay from to (current-buffer))
+ (setq show-paren-overlay (make-overlay from to nil t)))))
;;
;; Always set the overlay face, since it varies.
(overlay-put show-paren-overlay 'priority show-paren-priority)
[-- Attachment #3: Type: text/plain, Size: 14 bytes --]
--
Bastien
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Timer scheduling and cancel-timer
2013-01-22 13:57 ` Bastien
@ 2013-01-22 14:14 ` Stefan Monnier
0 siblings, 0 replies; 22+ messages in thread
From: Stefan Monnier @ 2013-01-22 14:14 UTC (permalink / raw)
To: Bastien
Cc: 'Tomohiro Matsuyama', 'Paul Eggert', Drew Adams,
emacs-devel
> The attached patch fixes the bug.
Thanks.
> Can anyone confirm this?
Looks credible, at least.
Stefan
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Timer scheduling and cancel-timer
2013-01-22 11:28 ` Stephen Berman
@ 2013-01-22 16:00 ` Stephen Berman
2013-01-22 16:09 ` Bastien
2013-01-24 16:32 ` Drew Adams
0 siblings, 2 replies; 22+ messages in thread
From: Stephen Berman @ 2013-01-22 16:00 UTC (permalink / raw)
To: Bastien
Cc: 'Tomohiro Matsuyama', 'Paul Eggert',
'Stefan Monnier', Drew Adams, emacs-devel
On Tue, 22 Jan 2013 12:28:46 +0100 Stephen Berman <stephen.berman@gmx.net> wrote:
> On Mon, 21 Jan 2013 19:50:44 -0800 "Drew Adams" <drew.adams@oracle.com> wrote:
>
>> I'm kind of surprised that no one else seems to be running into this problem.
>> Each time it arises, point follows a right paren, I believe.
>
> I hit it several times after updating from the trunk on 17 January but
> didn't have time to try to debug it, and also couldn't find a reliable
> recipe for reproducing it. Anyway, for whatever reason, I haven't seen
> it again for a couple of days (with the same build).
On Tue, 22 Jan 2013 14:57:49 +0100 Bastien <bzg@gnu.org> wrote:
> Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
>
>>> Perhaps it is worth reverting the code change you made that makes this happen
>>> now, until you find the bug?
>>
>> No, the change is there specifically to avoid hiding bugs under the
>> rug.
>
> The attached patch fixes the bug.
>
> Can anyone confirm this?
I just hit the bug again, and now realized it happens when point follows
an *unbalanced* right paren. So I tried your patch, and indeed it fixes
the bug. Thanks.
Steve Berman
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Timer scheduling and cancel-timer
2013-01-22 16:00 ` Stephen Berman
@ 2013-01-22 16:09 ` Bastien
2013-01-23 9:32 ` Bastien
2013-01-24 16:32 ` Drew Adams
1 sibling, 1 reply; 22+ messages in thread
From: Bastien @ 2013-01-22 16:09 UTC (permalink / raw)
To: Stephen Berman
Cc: 'Tomohiro Matsuyama', 'Paul Eggert',
'Stefan Monnier', Drew Adams, emacs-devel
Hi Stephen,
Stephen Berman <stephen.berman@gmx.net> writes:
> I just hit the bug again, and now realized it happens when point follows
> an *unbalanced* right paren. So I tried your patch, and indeed it fixes
> the bug. Thanks.
Thanks for confirming, I applied the patch in trunk.
--
Bastien
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Timer scheduling and cancel-timer
2013-01-22 16:09 ` Bastien
@ 2013-01-23 9:32 ` Bastien
2013-01-23 13:03 ` Stefan Monnier
0 siblings, 1 reply; 22+ messages in thread
From: Bastien @ 2013-01-23 9:32 UTC (permalink / raw)
To: Stephen Berman
Cc: 'Tomohiro Matsuyama', 'Paul Eggert',
'Stefan Monnier', Drew Adams, emacs-devel
Bastien <bzg@gnu.org> writes:
> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> I just hit the bug again, and now realized it happens when point follows
>> an *unbalanced* right paren. So I tried your patch, and indeed it fixes
>> the bug. Thanks.
>
> Thanks for confirming, I applied the patch in trunk.
Well, I thought I did, but I didn't.
My trunk directory was not bound to the remote branch
anymore after I did a fresh rsync (as suggested in this
page: http://savannah.gnu.org/bzr/?group=emacs)
I'll apply the patch again and make sure this goes into
trunk *for real* this time.
(As Alan would say, and because it feels good to say it
again, bzr is really a pain in the association list...)
--
Bastien
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Timer scheduling and cancel-timer
2013-01-23 9:32 ` Bastien
@ 2013-01-23 13:03 ` Stefan Monnier
2013-01-23 13:29 ` Bastien
0 siblings, 1 reply; 22+ messages in thread
From: Stefan Monnier @ 2013-01-23 13:03 UTC (permalink / raw)
To: Bastien
Cc: 'Tomohiro Matsuyama', Stephen Berman, emacs-devel,
Drew Adams, 'Paul Eggert'
> anymore after I did a fresh rsync (as suggested in this
> page: http://savannah.gnu.org/bzr/?group=emacs)
rsync is a bad idea here: it made sense back when the performance of the
bzr checkout sucked enough to justify the pains of rsync, but nowadays
I think it can only be a source of trouble.
Stefan
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Timer scheduling and cancel-timer
2013-01-23 13:03 ` Stefan Monnier
@ 2013-01-23 13:29 ` Bastien
2013-01-23 20:35 ` Stefan Monnier
0 siblings, 1 reply; 22+ messages in thread
From: Bastien @ 2013-01-23 13:29 UTC (permalink / raw)
To: Stefan Monnier
Cc: 'Tomohiro Matsuyama', 'Paul Eggert',
Stephen Berman, Drew Adams, emacs-devel
Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
>> anymore after I did a fresh rsync (as suggested in this
>> page: http://savannah.gnu.org/bzr/?group=emacs)
>
> rsync is a bad idea here: it made sense back when the performance of the
> bzr checkout sucked enough to justify the pains of rsync, but nowadays
> I think it can only be a source of trouble.
Okay, thanks. Can one admin update this page on Savannah?
I'm volunteering to be an admin and only focus on those tiny
changes, if that's useful.
--
Bastien
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Timer scheduling and cancel-timer
2013-01-23 13:29 ` Bastien
@ 2013-01-23 20:35 ` Stefan Monnier
2013-01-23 22:01 ` Bastien
0 siblings, 1 reply; 22+ messages in thread
From: Stefan Monnier @ 2013-01-23 20:35 UTC (permalink / raw)
To: Bastien
Cc: 'Tomohiro Matsuyama', 'Paul Eggert',
Stephen Berman, Drew Adams, emacs-devel
> Okay, thanks. Can one admin update this page on Savannah?
IIUC this text is shared by all projects on Savannah, so you'd need to
ask the Savannah admins to make the change.
Stefan
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Timer scheduling and cancel-timer
2013-01-23 20:35 ` Stefan Monnier
@ 2013-01-23 22:01 ` Bastien
0 siblings, 0 replies; 22+ messages in thread
From: Bastien @ 2013-01-23 22:01 UTC (permalink / raw)
To: Stefan Monnier
Cc: 'Tomohiro Matsuyama', 'Paul Eggert', emacs-devel,
Drew Adams, Stephen Berman
Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
>> Okay, thanks. Can one admin update this page on Savannah?
>
> IIUC this text is shared by all projects on Savannah, so you'd need to
> ask the Savannah admins to make the change.
Done, thanks.
--
Bastien
^ permalink raw reply [flat|nested] 22+ messages in thread
* RE: Timer scheduling and cancel-timer
2013-01-22 16:00 ` Stephen Berman
2013-01-22 16:09 ` Bastien
@ 2013-01-24 16:32 ` Drew Adams
2013-01-24 19:02 ` Bastien
1 sibling, 1 reply; 22+ messages in thread
From: Drew Adams @ 2013-01-24 16:32 UTC (permalink / raw)
To: 'Stephen Berman', 'Bastien'
Cc: 'Tomohiro Matsuyama', 'Paul Eggert',
'Stefan Monnier', emacs-devel
> > The attached patch fixes the bug.
> > Can anyone confirm this?
>
> I just hit the bug again, and now realized it happens when
> point follows an *unbalanced* right paren.
Yes, e.g., in a line of commented-out code. That's where I stumble onto it most
often.
> So I tried your patch, and indeed it fixes the bug.
Same here. In fact, it's hard for me to use Emacs without the patch. Hope it
gets applied soon, if it has not been applied already.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Timer scheduling and cancel-timer
2013-01-24 16:32 ` Drew Adams
@ 2013-01-24 19:02 ` Bastien
0 siblings, 0 replies; 22+ messages in thread
From: Bastien @ 2013-01-24 19:02 UTC (permalink / raw)
To: Drew Adams
Cc: 'Tomohiro Matsuyama', 'Stephen Berman',
emacs-devel, 'Stefan Monnier', 'Paul Eggert'
Hi Drew,
"Drew Adams" <drew.adams@oracle.com> writes:
> Same here. In fact, it's hard for me to use Emacs without the patch. Hope it
> gets applied soon, if it has not been applied already.
It has been fixed here:
http://git.savannah.gnu.org/cgit/emacs.git/commit/?h=trunk&id=b7e2d3
Best,
--
Bastien
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Timer scheduling and cancel-timer
2013-01-20 19:22 ` Paul Eggert
2013-01-20 21:04 ` Drew Adams
@ 2013-03-31 11:17 ` Tomohiro Matsuyama
2013-03-31 16:44 ` Michael Heerdegen
1 sibling, 1 reply; 22+ messages in thread
From: Tomohiro Matsuyama @ 2013-03-31 11:17 UTC (permalink / raw)
To: Paul Eggert; +Cc: emacs-devel
> On 01/20/2013 07:58 AM, Tomohiro Matsuyama wrote:
> > (setq my-timer
> > (run-with-timer
> > nil 0.1
> > (lambda ()
> > (when my-timer
> > (cancel-timer my-timer)
> > (setq my-timer nil)
> > (sit-for 0.3)))))
> >
> > After evaluating this code several times, you may see "zombie" timers
> > in timer-list, though the code intends to keep at most one timer.
>
> Hmm, isn't that due to a race in the above code?
> A timer can fire when a timer action is running.
>
> Do you get zombie timers with the following?
> It should avoid the race.
>
> (setq my-timer
> (run-with-timer
> nil 0.1
> (lambda ()
> (let ((m my-timer))
> (when m
> (cancel-timer m)
> (setq my-timer nil)
> (sit-for 0.3))))))
I still got zombie timers. Same if I replace sit-for with sleep-for.
No one can reproduce this problem?
Regards,
Tomohiro
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Timer scheduling and cancel-timer
2013-03-31 11:17 ` Tomohiro Matsuyama
@ 2013-03-31 16:44 ` Michael Heerdegen
0 siblings, 0 replies; 22+ messages in thread
From: Michael Heerdegen @ 2013-03-31 16:44 UTC (permalink / raw)
To: emacs-devel; +Cc: Paul Eggert, emacs-devel
Tomohiro Matsuyama <tomo@cx4a.org> writes:
> > > (setq my-timer
> > > (run-with-timer
> > > nil 0.1
> > > (lambda ()
> > > (when my-timer
> > > (cancel-timer my-timer)
> > > (setq my-timer nil)
> > > (sit-for 0.3)))))
> > >
> > > After evaluating this code several times, you may see "zombie" timers
> > > in timer-list, though the code intends to keep at most one timer.
I see that, too.
To reveal what's happening, I ran the following experiment:
--8<---------------cut here---------------start------------->8---
(defvar my-timer nil)
(defun start-the-timer ()
(interactive)
(setq my-timer
(run-with-timer
0 0.1
(lambda ()
(cancel-timer my-timer)
(sit-for 0.3)))))
(advice-add 'timer-event-handler :before
(lambda (timer)
(when (and (eq timer my-timer)
(not (memq my-timer timer-list)))
(message "Why is this ever reached?"))))
--8<---------------cut here---------------end--------------->8---
If you call `start-the-timer', you get the message "Why is this ever
reached?" over and over.
Obviously, although the timer object created has been successfully
canceled (i.e., removed from `timer-list'), the C code still calls it
repeatedly with `timer-event-handler'. Dunno why, but that's not good.
Regards,
Michael.
^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2013-03-31 16:44 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-01-20 15:58 Timer scheduling and cancel-timer Tomohiro Matsuyama
2013-01-20 19:22 ` Paul Eggert
2013-01-20 21:04 ` Drew Adams
2013-01-20 21:35 ` Drew Adams
2013-01-21 1:36 ` Stefan Monnier
2013-01-21 1:39 ` Drew Adams
2013-01-22 3:50 ` Drew Adams
2013-01-22 11:28 ` Stephen Berman
2013-01-22 16:00 ` Stephen Berman
2013-01-22 16:09 ` Bastien
2013-01-23 9:32 ` Bastien
2013-01-23 13:03 ` Stefan Monnier
2013-01-23 13:29 ` Bastien
2013-01-23 20:35 ` Stefan Monnier
2013-01-23 22:01 ` Bastien
2013-01-24 16:32 ` Drew Adams
2013-01-24 19:02 ` Bastien
2013-01-22 13:34 ` Stefan Monnier
2013-01-22 13:57 ` Bastien
2013-01-22 14:14 ` Stefan Monnier
2013-03-31 11:17 ` Tomohiro Matsuyama
2013-03-31 16:44 ` Michael Heerdegen
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).