FinalizationRegistry.prototype.cleanupSome integration with HTML

[syg]

Gated on #4571.

WeakRefs is a TC39 proposal currently at Stage 3 and may ship soon in Chrome.

In the April 2020 TC39, Apple expressed desire to remove FinalizationRegistry.prototype.cleanupSome. There was no consensus in TC39 for its removal. Instead, TC39 made that method normative optional (i.e. up to hosts to ship, and how) to unblock the rest of the proposal.

Crucially, this means that it's up to HTML spec for if and how to ship FinalizationRegistry.prototype.cleanupSome. The thread above has Apple's objections and Mozilla and others' counter-objections.

I'd like to propose one of the original proposals that Apple rejected: ship cleanupSome only to worker threads, since it is explicitly designed to be used for long-running off-thread applications, like wasm. Now that TC39 has made the method normative optional, I'd like to continue the discussion here.

Cc @codehag for Mozilla and @kmiller68 for Apple. Please cc other stakeholders.

[annevk]

Worker threads is a tad too vague, should this follow an agent's [[CanBlock]]?

[littledan]

When we discussed this previously, it wasn't clear whether it should always match [[CanBlock]], or maybe it should be a separate bit. I don't really have enough background here to know; for example, I don't know whether we might want to make cleanupSome available to Worklets.

[annevk]

Whenever we set [[CanBlock]] to false in the web platform the reason is that the agent runs performance-critical code (e.g., a worklet might be responsible for audio processing). As I understand it cleanupSome effectively blocks, which would not be acceptable for any such agent. Are there scenarios where an agent with [[CanBlock]] set to true might nevertheless want to disable cleanupSome?

[syg]

cleanupSome doesn't effectively block, not in the sense of "thread can't make progress until programmatically unblocked up by an external source". cleanupSome is no different than any other possibly expensive synchronous operation.

I see no technical reason to disable cleanupSome on the main thread, and with my pure software engineer hat on, I would prefer it remains available on all threads. I offered that solution more as a compromise on the hopes that Apple will come around, and since disabling cleanupSome on the main thread doesn't preclude the intended use of the API.

(I should note that Apple's contention seems to be all about the kind of programs that are encouraged, regardless of [[CanBlock]] and any main-thread-off-thread distinction.)

[annevk]

To be clear, I'd consider expensive operations to be effectively blocking and not desirable on web platform [[CanBlock]] is false agents. It means you might end up skipping a frame, not encode some audio in time, not process requests in a timely manner, etc.

[littledan]

I don't know what's expensive/blocking about cleanupSome. I think the issue is more that, cleanupSome is useful in cases where it's difficult to yield to the event loop and come back. One use case of that could be long-running computational code. (I was wondering if another potential use case could be short-running worklet code, but probably this one doesn't make sense.) It would be that other, surrounding code which effectively "blocks", not the call to cleanupSome. The question is, whether we want to encourage this coding style, of having code which doesn't yield to the event loop, by providing an API that's useful in the context of this style, and if so, in which contexts we want to permit it.

[syg]

The question is, whether we want to encourage this coding style, of having code which doesn't yield to the event loop, by providing an API that's useful in the context of this style, and if so, in which contexts we want to permit it.

This is also my understanding of where TC39 ended up. In the TC39 discussion, Apple's position was "no, we should discourage this coding style". Firefox's position was "yes, we should allow this coding style for wasm". Chrome's position was "yes, we should allow this coding style for wasm in workers".

Please correct me @codehag and @kmiller68 for any misrepresentations above.