-
Notifications
You must be signed in to change notification settings - Fork 41
cleanupSome on main thread questions #197
Comments
Also cc @erights |
I guess I'd like to clarify my position a bit. It's not so much about synchronous work as it is about the current architecture of the Web as a whole. In particular, the Web Platform is largely event driven and previous systems that try deviate from this have resulted in poor user experiences. Namely, Plugins. Looking from the the web platform as a whole, we think that the use cases for this promote an architectural philosophy differs from the web as it exists today, which result in bad user experiences. While I respect that other platforms for JS exist (and thrive) I don't want that to come at the expense of the Web Platform. In order for cleanupSome to proceed on the web, we'd like to see a cohesive transpilation proposal that covers: integration of the html event loop (including idle sleep), event handling, animation frames, message passing, tasks and micro tasks, accessibility, and termination. Some of these make sense for JS in isolation but this proposal also has implications for WebAssembly. Unfortunately, this means the WebAssembly issues will need to be addressed as well. So, we are going to ask that the committee consider separating cleanupSome from the rest of WeakRefs tomorrow. I'd also like to apologize for the lateness of this feedback. These overarching concerns only came up once I started sharing this proposal with the rest of the WebKit team during implementation. In isolation, this proposal seemed innocuous (modulo compatibility). |
It is up to the host to determine what gets cleaned up during a |
This isn't quite the same an any of @syg 's bullets. But I think it is similar enough that it is part of the same menu of choices. The difference is this one fits within the current proposal without changes or additions. |
I think that practically making
So for any application that does not test in a browser that does a no-op |
To answer the initial question: cleanupSome was really intended for workers, so from our perspective, the proposal to throw on the main thread or to leave it up to the host are both fine and we would support it.
The WebAssembly use case is important to us. We want to make sure that long running calculations that do not return to the event loop can be supported. Before we move to separating this into it's own proposal, I want to make sure that this will still be possible to support and I want to make sure that we can come to an agreement about that. |
I believe that ship has already sailed with SAB and Atomics. Realistically workers are able to have this kind of architecture today on the web. Since we're talking about making SAB normative optional, can't we make |
Why not make it normative that |
Why not make it normative (web normative, not js normative) that when [[CanBlock]] is false |
The concern is that even in a Worker |
@kmiller68 are you saying that even if this style is used only in a worker that it would create a poor user experience? How? |
Yes, for the same reasons that previous black-box custom event loop apps (e.g. flash) did. If the goal is to enable those types of apps, I'd like to know why we're not retreading the same road. |
Those type of custom event loop programs are possible today without I'm actually not sure |
@mhofman thanks for pointing that out. I'd forgotten about that. Yes, that's why we made the separation (initially, in a more awkward way). The JS-to-wasm acyclic gc issue doesn't need weakrefs, just finalization. Needing weakrefs during a turn is indeed useful functionality explicitly not available to long-running single job programs. |
The functionality of weakness is not available. the api still is with its normal in-turn meaning is still available of course. |
In any case, at tc39 we settled this today as literally normative optional. The signal is only the presence or absence of the |
How is that good for cross-host libraries? Also, how does that address your point above about allowing it to no-op so you can call it either way? |
Hi @annevk I prefer the no-op version. But the normative-optional feature testing version was the one we were able to jointly agree on. I am happy enough with it --- especially now that JS has optional chaining! |
@kmiller68 brought up the concern that
FinalizationRegistry#cleanupSome
is counter to the web API philosophy where we shouldn't encourage synchronous work. While the spec already does allowcleanupSome
to always be a no-op, there is a practical desire for the web browsers to align here. In other words, if Safari always no-opscleanupSome
on the main thread but Chrome always processes finalizers, that runs a larger interop risk in practice thancleanupSome
behaving differently due to GC timing anyway.There are two ways forward:
cleanupSome
entirely. I strongly, strongly consider this a non-starter. It is well-motivated for the web worker use case and non-web use cases, and the current TC39 consensus is that we agreed to its usefulness.cleanupSome
is available or is able to do something:cleanupSome
should throw, e.g. on the main thread.cleanupSome
normative option for hosts at Realm-creation time, like what TC39 just decided forSharedArrayBuffer
. This makes feature testing slightly easier.cleanupSome
and the question of if and how to allow synchronous processing of finalization events to a different proposal and demote it to Stage 2.Concretely, I propose 2.ii to be fully fleshed out in the HTML integration patch, since Keith's concern is mainly a host concern in HTML where the main thread has distinctly different API availability expectations than worker threads.I now propose option 3, given the severity of concern from Apple. Apple believes allowing synchronous processing of finalization events to be counter to the goals of the web platform, and I think that question is orthogonal enough to be iterated upon without holding up the rest of the WeakRef proposal.
Thoughts from @codehag for Firefox also much appreciated.
The text was updated successfully, but these errors were encountered: