You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The way AbortController is implemented (with transferrable support) makes it very slow to use and I'm currently recommending everyone to use the npm package (abort-controller) instead.
I don't think transferrable use of abort controller is very common and it's a bit unfortunate that such an unusual use case has significant performance impact on the common use.
Is there any way to improve this? As far as I understand it's not possible to improve the current implementation with transferrable support without further features from V8. Which leaves the question on whether we can add an option to disable/enable the transferrable implementation? That way users that don't need it can opt-out and get better performance.
Sorry for being a bit disconnected. We discussed this issue at the Collab Summit in Austin. We can remove the ability to transfer the AbortController. It is not part of the standard so there's good justification there. It was added as a convenience but given the performance hit, it's fine to remove that.
We don't need a separate TransferableAbortController class. We could, however, have a util.transferableAbortController() or something that returns a regular AbortController that has been marked as transferable per the current behavior. That would give current users a good transition. (An API like AbortController.transferable() would be better but we really shouldn't be hanging non-standard things off AbortController.
That said, I do plan on opening an issue in the DOM spec about making AbortController transferable officially, I just haven't been able to get to it yet.
There's really no reason to implement util.transferableAbortController in c++. Just use the makeTrsnsferable util with a regular AbortController. You can even keep the existing kClone/kDeserialize methods on the existing AbortController class.
Activity
ronag commentedon May 20, 2022
@mcollina @addaleax @jasnell @mscdex
ronag commentedon May 20, 2022
Even better if we could somehow detect the possible use of transferrable and then dynamically enable it.
mcollina commentedon May 21, 2022
A quick search on GitHub showed that AbortController is not transferable by the spec: whatwg/dom#438.
I propose we:
ronag commentedon May 21, 2022
I think then we can implement AbortController in pure js? @benjamingr
benjamingr commentedon May 22, 2022
The one who pushed for this was @jasnell so I'd want him to weigh in but sgtm.
jasnell commentedon Jun 11, 2022
Sorry for being a bit disconnected. We discussed this issue at the Collab Summit in Austin. We can remove the ability to transfer the AbortController. It is not part of the standard so there's good justification there. It was added as a convenience but given the performance hit, it's fine to remove that.
We don't need a separate
TransferableAbortControllerclass. We could, however, have autil.transferableAbortController()or something that returns a regularAbortControllerthat has been marked as transferable per the current behavior. That would give current users a good transition. (An API likeAbortController.transferable()would be better but we really shouldn't be hanging non-standard things offAbortController.That said, I do plan on opening an issue in the DOM spec about making
AbortControllertransferable officially, I just haven't been able to get to it yet.mcollina commentedon Jun 11, 2022
Let's recap the plan:
mcollina commentedon Jun 11, 2022
Have I missed anything @jasnell?
jasnell commentedon Jun 11, 2022
There's really no reason to implement util.transferableAbortController in c++. Just use the makeTrsnsferable util with a regular AbortController. You can even keep the existing kClone/kDeserialize methods on the existing AbortController class.
jasnell commentedon Jun 12, 2022
PR opened #43388
mcollina commentedon Aug 16, 2022
fixed in #44048