-
Notifications
You must be signed in to change notification settings - Fork 29.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
events: support signal in EventTarget #36258
Conversation
@@ -200,10 +200,12 @@ class Listener { | |||
previous.next = this; | |||
this.previous = previous; | |||
this.listener = listener; | |||
// TODO(benjamingr) these 4 can be 'flags' to save 3 slots |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is in order to fix an unrelated bug where we cache the next handler in our dispatchEvent
and still call it. Added a test or this case below.
} | ||
// TODO(benjamingr) make this weak somehow? ideally the signal would | ||
// not prevent the event target from GC. | ||
signal.addEventListener('abort', () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FWIW: we should really add support for "weak" event listeners that is:
signal[kAddWeakListener]('abort', () => {
this.removeEventListener(type, listener, options);
});
That would not retain the event target only because the signal exists (since if no one cares about the event retaining it for abort
is mostly meaningless). I think a good path forward is:
- Make our listener list accept
WeakRef
s to listeners - Put said listener behind a WeakRef
- Make our dispatch unwrap WeakRefs when it finds them.
@addaleax @jasnell if you think that's reasonable I'm happy to do this (either here or in a new PR)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that’s reasonable here, yes… it’s way more common to think that you need a weak listener than it is to actually need one, so I wouldn’t expose this as public API, but for internal usage this sounds good :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My only concern there would be the potential additional performance cost. If the dispatch only incurs that cost for weak handlers then I'm definitely +1
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jasnell great, I'll do that at a separate pull request then.
@addaleax there are discussions for other use cases for this e.g. creating linked signals whatwg/dom#920 - there is a good explanation here: #35990 (comment)
I think we're running into the same issue with AbortSignal multiple times: If the resource will no longer be aborted and we're "done" with it we need to make sure that retaining the signal does not retain the resource. With some resources (like http.request, streams in general and timers) this is a relatively easy problem since we know when abort will be meaningless but with addEventListener
and other resources this is less clear cut (hence the advantage of a weak handler to not have to manage this).
Kind of embarrassing that all the browsers are going to have this feature before us 😅 Though I am happy to wait a few more days for the whatwg/dom PR to be merged if that's a concern. |
Landed in 4a741b8...ef8d0e9 |
PR-URL: #36258 Fixes: #36073 Reviewed-By: James M Snell <[email protected]>
PR-URL: #36258 Fixes: #36073 Reviewed-By: James M Snell <[email protected]>
PR-URL: #36435 Notable changes: * child_processes: * add AbortSignal support (Benjamin Gruenbaum) (#36308) * deps: * update ICU to 68.1 (Michaël Zasso) (#36187) * events: * support signal in EventTarget (Benjamin Gruenbaum) (#36258) * graduate Event, EventTarget, AbortController (James M Snell) (#35949) * http: * enable call chaining with setHeader() (pooja d.p) (#35924) * module: * add isPreloading indicator (James M Snell) (#36263) * stream: * support abort signal (Benjamin Gruenbaum) (#36061) * add FileHandle support to Read/WriteStream (Momtchil Momtchev) (#35922) * worker: * add experimental BroadcastChannel (James M Snell) (#36271)
PR-URL: nodejs#36258 Fixes: nodejs#36073 Reviewed-By: James M Snell <[email protected]>
PR-URL: #36435 Notable changes: * child_processes: * add AbortSignal support (Benjamin Gruenbaum) (#36308) * deps: * update ICU to 68.1 (Michaël Zasso) (#36187) * events: * support signal in EventTarget (Benjamin Gruenbaum) (#36258) * graduate Event, EventTarget, AbortController (James M Snell) (#35949) * http: * enable call chaining with setHeader() (pooja d.p) (#35924) * module: * add isPreloading indicator (James M Snell) (#36263) * stream: * support abort signal (Benjamin Gruenbaum) (#36061) * add FileHandle support to Read/WriteStream (Momtchil Momtchev) (#35922) * worker: * add experimental BroadcastChannel (James M Snell) (#36271)
PR-URL: #36435 Notable changes: * child_processes: * add AbortSignal support (Benjamin Gruenbaum) (#36308) * deps: * update ICU to 68.1 (Michaël Zasso) (#36187) * events: * support signal in EventTarget (Benjamin Gruenbaum) (#36258) * graduate Event, EventTarget, AbortController (James M Snell) (#35949) * http: * enable call chaining with setHeader() (pooja d.p) (#35924) * module: * add isPreloading indicator (James M Snell) (#36263) * stream: * support abort signal (Benjamin Gruenbaum) (#36061) * add FileHandle support to Read/WriteStream (Momtchil Momtchev) (#35922) * worker: * add experimental BroadcastChannel (James M Snell) (#36271)
This pull request lands cleanly on v14.x-staging, but I think the |
@targos I think it's fine not to land given |
Refs: #36258 PR-URL: #43170 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Masashi Hirano <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
Refs: #36258 PR-URL: #43170 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Masashi Hirano <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
Refs: #36258 PR-URL: #43170 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Masashi Hirano <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
Refs: #36258 PR-URL: #43170 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Masashi Hirano <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
Refs: #36258 PR-URL: #43170 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Masashi Hirano <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
Refs: nodejs/node#36258 PR-URL: nodejs/node#43170 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Masashi Hirano <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
Fixes: #36073
This is this feature whatwg/dom#911 I've implemented the spec I worked on in whatwg/dom#919 and ported the WPTs from web-platform-tests/wpt#26472
This is following implementations from Chrome and Firefox and positive signals regarding the spec. I am happy to put this behind an experimental warning if you think that's a good idea.
Ping @jasnell
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes