Skip to content
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

Stuff never gets cleaned up for workers #6831

Open
domenic opened this issue Jul 7, 2021 · 1 comment
Open

Stuff never gets cleaned up for workers #6831

domenic opened this issue Jul 7, 2021 · 1 comment

Comments

@domenic
Copy link
Member

domenic commented Jul 7, 2021

Spotted by @yutakahirano in w3c/webtransport#127 (comment)

Documents clean up their WebSockets, EventSource, and timers as part of the "unloading document cleanup steps".

Workers only clean up their timers, at the end of run a worker after their event loop has shut down.

So per spec I believe the server is never told about a WebSocket connection disappearing if that connection is initiated by a worker. Is that what people implement?

What about EventSource? That seems like less of an issue since it just relies on termininating a fetch algorithm, and in general we probably want to terminate a lot of fetch algorithms (which is not well-specified now).

I think it would be nice to introduce "global object cleanup steps" which specs like WebTransport could use for the purposes discussed there, and maybe we could move WebSocket/EventSource/timer cleanup there. That way they don't need to separately hook into window/shared worker/service worker/dedicated worker cleanup locations.

But the details might be tricky, e.g. documents deal with bfcache and the salveagable state in a special way (/cc @rakina @fergal), and we probably want spec authors to think through that interaction in some detail. Similarly shared/service workers might have different considerations than dedicated workers. So I'm not sure.

@rakina
Copy link
Member

rakina commented Jul 9, 2021

I think having a "global object cleanup steps" makes sense, we can just pass whether this is for the owner going away permanently or not (the document is salvageable), and maybe "is this the only owner?" for shared workers?

I guess it is a bit awkward to have both that and independent specifications listening to "salvageability changes" as recommended in w3ctag/design-principles#317, but maybe we can just call that out in a comment there too.

(btw @fergald is the BFCache Fergal :) )

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

2 participants