-
-
Notifications
You must be signed in to change notification settings - Fork 34.2k
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_idassigned would have a conflict.- Possible solution: Piggy back on the preexisting
async_idand simply not assign a new one, and skip runninginit().
Conclusion: Not possible because an object that is meant to be assigned anasync_idhasn't had it assigned before being passed toactive(). Thus assigning one, and firinginit()with atype === 'Timeout'. - Possible solution:
timershas it's ownasync_id_symbolseparate 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_idis assigned innet.Socket()and thatasync_idis passed toTCPWrap.- issue: Because
init()won't fire untilTCPWrapis constructed (which in this case isn't actually until.listen()fornet.Server()) users will seeasync_ids 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 theTCPWrapinstance, but it still has its ownsetTimeout()method. Making it nearly impossible to pre-assign theasync_idand 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 === falseand 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._calledis set totruebefore 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.