-
-
Notifications
You must be signed in to change notification settings - Fork 33.3k
Description
Tracking issue for difficulties using the API in #14208.
Here's a bullet list of issues, and walk through to explain the logic behind each conclusion:
Timers
The exposed APIs of active()
/enroll()
/unenroll()
creates the following issues:
-
Arbitrary objects can be passed to all three of those. Meaning constructors that have already had an
async_id
assigned would have a conflict.- Possible solution: Piggy back on the preexisting
async_id
and simply not assign a new one, and skip runninginit()
.
Conclusion: Not possible because an object that is meant to be assigned anasync_id
hasn't had it assigned before being passed toactive()
. Thus assigning one, and firinginit()
with atype === 'Timeout'
. - Possible solution:
timers
has it's ownasync_id_symbol
separate from the one exported byprocess.binding('async_wrap')
and have the object treated as a completely separate asynchronous resource.
Conclusion: Most plausible option, but still fails in a few edge cases as will be discussed.
- Possible solution: Piggy back on the preexisting
-
Option [1.2] has the edge case of possibly not being able to acquire the correct
trigger_id
. For example:const { async_id_symbol } = process.binding('async_wrap'); const s = new net.Socket(); console.log(s[async_id_symbol] === -1) s.setTimeout(10, () => {});
Though this case is simple, and the reason for the new API. What happens is the
async_id
is assigned innet.Socket()
and thatasync_id
is passed toTCPWrap
.- issue: Because
init()
won't fire untilTCPWrap
is constructed (which in this case isn't actually until.listen()
fornet.Server()
) users will seeasync_id
s in their graphs that haven't runinit()
yet. - issue: More complex cases break down quickly. For example
http.OutgoingMessage()
isn't directly attached to the object that has the reference to theTCPWrap
instance, but it still has its ownsetTimeout()
method. Making it nearly impossible to pre-assign theasync_id
and then safely pass it down the object chain to reachTCPWrap
.
- issue: Because
-
Usage of
enroll()
is completely optional, since any object can be passed directly toactive()
, but node internals uses bothHandleWrap::Close()
and/orunenroll()
to close the resource.
Conclusion: Callingdestroy()
for on the timer'sasync_id_symbol
, anactive()
object needs to check the following things:Timeout#close()
willemitDestroy()
iftimer._called === false
and if the timer hasn't beenunenroll()
'd.- After the
_onTimeout()
callback has run, regardless of whether the callback threw or not. If the error is handled then it'll be called later in the event loop. If not then the process is exiting and it didn't matter anyway.
Note:timer._called
is set totrue
before the callback runs, so callingtimer.close()
during the_onTimeout()
callback that value is safe to check inTimeout#close()
. unenroll()
willemitDestroy()
if the timer hasn't been closed, and iftimer._called === false
.
Note: Part of the problem here is that while you don't need to pass pass aTimeout()
instance toactive()
orenroll()
(though you can...) it is possible to pass aTimeout()
instance tounenroll()
. Which is basically the same as passing it toclearTimeout()
.
Note: This means assigning theasync_id_symbol
(thus callingemitInit()
) should happen in the call toactive
, andenroll()
should simply be seen as a helper function to add properties to the object. Butunenroll()
can callemitDestroy()
. This makes for a somewhat unintuitive API.
Note: This isn't everything, but is enough to get started. Will update soon with the remainder of the known edge cases.