clearTimeout after timer is queued/pending

[Richard Maher]

Hi,

Can someone please clarify the behaviour of clearTimeout for me?

If the timer has (in search of correct terminology here) elapsed, fired, is
pending, but the function specified with setTimeout cannot be delivered
because the EDT is busy on another event that is attempting to cancel the
previous timeout - will the timeout function still be executed?

IOW, the timer itself has expired, the cancel was too late, but the function
has yet to be delivered as it is presumably sitting in the stack somewhere,
and the currently executing function says clearTimeout. Is it smart enough
to prevent delivery of the setTimeout function or do I have to incorporate
some sort of amDying flag for the timeout function to see and then
exit/abort?

I'm guessing that clearTimeout is not that clever and the
anDying/shuttingDown flag is a requirement but I had thought (at least in ye
olde days) that a cancelTimeout was effectual until the function had been
delivered.

Cheers Richard Maher

 

[Evertjan.]

Richard Maher wrote on 17 jan 2010 in comp.lang.javascript:

Can someone please clarify the behaviour of clearTimeout for me?

If the timer has (in search of correct terminology here) elapsed,
fired, is pending, but the function specified with setTimeout cannot
be delivered because the EDT is busy on another event that is

What is an EDT?

attempting to cancel the previous timeout - will the timeout function
still be executed?

Depends on what you mean with EDT,
but in general timeouts fire when their time comes,
unless previously cancelled.

IOW, the timer itself has expired, the cancel was too late, but the
function has yet to be delivered as it is presumably sitting in the
stack somewhere,

The firing means the the function called by that firing executes.
The firing itself can be delayed, by another process.

and the currently executing function says clearTimeout.

Impossible, as ther is no difference between firing and executing in a
monothreaded script execution engine.

Is it smart enough to prevent delivery of the setTimeout
function or do I have to incorporate some sort of amDying flag for the
timeout function to see and then exit/abort?

Javascript in most if not all implementations is monothreaded.

I'm guessing that clearTimeout is not that clever and the
anDying/shuttingDown flag is a requirement but I had thought (at least
in ye olde days) that a cancelTimeout was effectual until the function
had been delivered.

Untill the setTimeout has fired, because then evn the pointer to that
setTimeout is no longer pointing to anything.

From the moment of firing, the thread is busy with the called functuon,
so doing anything outsidem that function is impossible.

 

[Gregor Kofler]

Richard Maher meinte:

Hi,

Can someone please clarify the behaviour of clearTimeout for me?

If the timer has (in search of correct terminology here) elapsed, fired, is
pending, but the function specified with setTimeout cannot be delivered
because the EDT is busy on another event that is attempting to cancel the
previous timeout - will the timeout function still be executed?

IOW, the timer itself has expired, the cancel was too late, but the function
has yet to be delivered as it is presumably sitting in the stack somewhere,

How is that supposed to happen? (IOW: It doesn't happen.)

and the currently executing function says clearTimeout.

Current browser implementations of ECMAScript are single-threaded.

Gregor

 

[Richard Maher]

Hi Gregor, Evertjan,

Richard Maher meinte: somewhere,

How is that supposed to happen? (IOW: It doesn't happen.)

I guess not. In my case (after throttling back the server with a 1 sec
delay) I discovered that is was the SEND callbackroutine that was
perpetuating the loop rather than the fade (or any other) timeout. The
"shutdown" flag will now handle that.

Current browser implementations of ECMAScript are single-threaded.

Yes, but not knowing the timer-queue or timer-thread implementation I was
mislead by my history with VMS and Asynchronous System Traps (ASTs) and
Timer Queues where the timer could elapse but then the AST was queued on the
stack and un-cancelable. (And all with just one thread)

Gregor

Cheers Richard Maher

 

[Lasse Reichstein Nielsen]

Can someone please clarify the behaviour of clearTimeout for me?

In which browser?

If the timer has (in search of correct terminology here) elapsed, fired, is
pending, but the function specified with setTimeout cannot be delivered
because the EDT is busy on another event that is attempting to cancel the
previous timeout - will the timeout function still be executed?

Probably not. But what have you tried?

I guess this would be a suitable test:

<script>
var id = setTimeout(function(){ alert("running"); }, 1000);
var waitfor = new Date().getTime() + 2000;
while (new Date().getTime() < waitfor) {}
clearTimeout(id);
</script>

The one browser I just checked did cancel the timeout even if the
timer had run out.

IOW, the timer itself has expired, the cancel was too late, but the function
has yet to be delivered as it is presumably sitting in the stack somewhere,

More likely it wass sitting in some kind of queue, waiting for the
script to end. The cancellation would remove it from the queue, and
when the script ends, there is nothing waiting to happen.

and the currently executing function says clearTimeout. Is it smart enough
to prevent delivery of the setTimeout function or do I have to incorporate
some sort of amDying flag for the timeout function to see and then
exit/abort?

Check the browsers you need it to work in.

The only "standard" covering it is the not-yet-standard HTML 5. You can
see if it specifies anything about your case.

As I read it, it should actually queue a task when the timer runs out,
and cancelling the timeout after that doesn't remove the task from the
queue.
I.e., to be compatible with the current wording of HTML 5, you would
need a flag to avoid the function doing something.

/L

 

[Jorge]

(...)
I.e., to be compatible with the current wording of HTML 5, you would
need a flag to avoid the function doing something.

Yep. And that will work for sure, always, in any browser, regardless
of what it does -or doesn't- do with the timer queue after a
clearTimeout.

 

[Jorge]

Yep. And that will work for sure, always, in any browser, regardless
of what it does -or doesn't- do with the timer queue after a
clearTimeout.

In any case, I would -in addition- clear the timeout too...