Skip to content
This repository has been archived by the owner on Jan 25, 2022. It is now read-only.

Should we coarsen the atomicity unit? #57

Closed
erights opened this issue Dec 14, 2018 · 2 comments
Closed

Should we coarsen the atomicity unit? #57

erights opened this issue Dec 14, 2018 · 2 comments

Comments

@erights
Copy link
Contributor

erights commented Dec 14, 2018

Currently, the weakref proposal specifies an individual turn (i.e., "job" in EcmaScript terminology) as the atomicity unit. A turn/job is everything that happens from one empty user stack state to the next empty user stack state. Any implementation that uses a coarser unit, consisting of several turns, will satisfy the current spec as long as the boundaries between these units are also turn boundaries, i.e., empty stack states.

At the November tc39 meeting @tschneidereit suggested that the atomicity unit be coarsened in the spec to match what implementations are expected to do anyway, which is to always service a non-empty promise queue before servicing any other turns, and to only deal with WeakMap atomicity issues in states where the stack and promise queue were both empty.

If this assumption about implementations held, then this would be a possible choice, with pros and cons to argue through. (I've changed my opinion several times.) But nodejs/promise-use-cases#25 indicates that the premise is false. Implementations might not always service the promise queue at strictly higher priority. The reasons for not doing so are well motivated and plausible. However this particular bug is settled, we would have to preclude this possibility for all future implementations if we coarsened the atomicity unit this way.

@erights erights changed the title Should we coarsen atomicity unit? Should we coarsen the atomicity unit? Dec 14, 2018
@littledan
Copy link
Member

@erights I'm not sure what you mean about that premise being false. I believe Node.js does service the Promise job queue with strictly higher priority.

I'd like to suggest that we use an embedder-level job to run finalizers, for reasons explained in #61 (comment) . The semantics proposed there would have the effect, in HTML, of indeed "coarsening the atomicity unit", as you put it. It's hard to say what they would do for environments in general, as at some point, we have to leave some aspects of the event queue to the host, but maybe we could include certain requirements on all host environments to do something analogous. I'd be interested to hear your thoughts.

@littledan
Copy link
Member

We've decided to let the host determine the atomicity unit in #86 , and reached Stage 3 consensus on this design.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants