Repository navigation
‘timersPromises.setInterval()’ doesn’t keep the event loop active #45224
Description
Version
v18.12.0
Platform
Darwin leafac--mac-mini.lan 21.6.0 Darwin Kernel Version 21.6.0: Mon Aug 22 20:20:05 PDT 2022; root:xnu-8020.140.49~2/RELEASE_ARM64_T8101 arm64
Subsystem
No response
What steps will reproduce the bug?
As far as I understand from having read the documentation, timersPromises.setInterval() was supposed to keep the event loop active, in much the same way that other timers including setInterval() do. That’s why one of the possible options is ref.
But that doesn’t seem to be working.
Here’s an example program:
// index.mjs
import timers from "node:timers/promises";
timers.setInterval(1000);This program exits immediately. I tried changing the ref option, including setting it to true explicitly, to no effect.
Here’s a similar program using setInterval(), which does keep the event loop active and does not terminate right away:
// index.mjs
setInterval(() => {});This may seem like a silly program, but sometimes it’s actually useful to have a dummy timer like that to exert more control over the event loop and when it terminates.
How often does it reproduce? Is there a required condition?
No response
What is the expected behavior?
No response
What do you see instead?
—
Additional information
No response
Activity
mscdex commentedon Oct 28, 2022
Don't you need to
awaitthe returned value in order for the delay to occur?theanarkh commentedon Oct 28, 2022
timers.setInterval(1000).next()works. The timer is not created untilnextis executed.leafac commentedon Oct 28, 2022
@mscdex Thanks for the response.
No, I don’t think that
awaiting for the promise should make any difference. I think that the timer should have been registered and kept the event loop active, in much the same way thatsetInterval()does.Note that the desired behavior I’m describing is what occurs with
timers.setTimeout(), even if you don’tawaitfor the promise. The following program, for example, takes one second to terminate:@theanarkh Thanks for the response.
Great idea. I can confirm that
timers.setInterval(1000).next()does keep the event loop active.I think it’s a bit weird that it appears as if the timer is only being registered if you query for a value. I think that the timer should have been registered as soon as
timers.setInterval()is called.Do you agree?
Or do you think I’m misunderstanding something?
theanarkh commentedon Oct 28, 2022
Yeah, because this usage is different from
global.setInterval, so it may be a bit misleading, but the documentation mentioned thattimers.setIntervalreturn an async iterator, so we may need to understand how the async iterator works.leafac commentedon Oct 29, 2022
@theanarkh So I suppose we have an opportunity to either (in order of preference):
Modify
timers.setInterval()so that the timer is created and the event loop kept active as soon as possible, even if you don’t try to iterate over the iterator.Explain this behavior in more detail in the documentation.
What do y’all think we should do?
Also, for what it’s worth, it seems like TypeScript doesn’t know about the fact that you may call
.next()directly on theAsyncIterablereturned bytimers.setInterval(). To make this work in TypeScript I had to jump through the hoop of getting theAsyncIteratorunderneath:theanarkh commentedon Oct 29, 2022
I think we can explain this in more detail in the documentation :-).
doc: add more info for timer.setInterval
doc: add more info for timer.setInterval