How does this impact the web platform? (Cross-cutting concerns)

[domenic]

Several times on the web platform, we've denied feature requests due to not wanting to expose garbage collection behavior. The most prominent in my recent memory is detecting MessagePort closing: see

• Add onclose event to MessagePort whatwg/html#1766
• https://www.w3.org/Bugs/Public/show_bug.cgi?id=28813
• https://lists.w3.org/Archives/Public/public-whatwg-archive/2013Oct/thread.html#msg3

I think as part of exploring the cross-cutting concerns of this feature, this proposal and its champions need to answer at least the following questions:

• Would this proposal allow you to create your own "close" event for MessagePort, of the type that these threads are asking for? If so, please show the example code.
• If this proposal does do so, should we give developers what they've been asking for since at least 2013, and just add the event to browsers, now that the cat is out of the bag via weakrefs? (Needs consulting with browser teams.)

I'd also hope that the champions can collaborate with others to dig up other cases where web platform features have been omitted due to the desire not to expose GC, and help us evaluate whether we should revisit those decisions and APIs if weakrefs become shipped. I'll try to direct folks here to remind of us other cases.

[ljharb]

#16 and WebAssembly/interface-types#14 also seem relevant to this question.

[lars-t-hansen]

I seem to remember that there's a cluster of issues around dealing with workers that may have terminated and/or gone away; and that there are features one would normally want that aren't there because they would expose GC timing. For example, asking whether a Worker object represents a still-running worker. I admit my memory is a little hazy here.

In the context of workers I'm fairly sure the weakref proposal would not add the necessary power to detect the status of a worker unless the local Worker object stays alive even if not strongly referenced locally until the worker itself has been gc'd. In that case, I'd create a weakref that holds my worker and always access it through that weakref. But even then the status of the worker is different from the liveness of the underlying worker object; the worker could be dead, just not reaped, so it doesn't tell me whether I can reasonably send a message to it (or expect to receive a message from it).

[axkibe]

I read about the MessagePort thing before, Can someone explain me in laymen terms what really the issue would be, if the spawner of a MessagePort could guess by using weak-ref if the other has lost track of it's port?

I followed the links above, the close() event, the discussion revolved more around the question, if that event was really necessary rather than a security issue.

[littledan]

I'd suggest that, even as we add WeakRefs, we should still strongly recommend against using them for these sorts of cases. WeakRefs are best used for cleaning up memory, e.g., in caches or when allocating out of a larger ArrayBuffer. Maybe we can work together on a modified recommendation for the w3ctag design principles to reinforce the maintenance or this constraint. w3ctag/design-principles#100

[domenic]

I believe you meant to link to #31 in the last comment.

[littledan]

Now that w3ctag/design-principles#129 landed, I think we can turn it over to the W3C TAG to ensure that WeakRefs and the web platform interact well going into the future.