Add language to define Agents #522
Conversation
|
How are Agents and Realms related? Does a different agent necessarily have a distinct Realm (even though an Agent might contain multiple Realms)? |
|
@ljharb, agents largely package up the already existing execution machinery: the context stack, the running execution context, the job queues. The Realm hangs off an execution context as it has always done, agents do not change that. The new indirection introduced here is that instead of the running execution context et al being ambient things, they are attached to the surrounding agent, which is a new ambient thing (and the only one). This brings us to an issue that I've discussed with @domenic. In the PR the Agent Record is very simple, it has just two boolean properties (the shared memory spec adds more). We could reify the existing ambient things (running execution context, context stack, job queues) and turn them into fields of the Agent Record, instead of letting them just be "attached to" the surrounding agent. I have not done so since (a) the change would be larger and the benefits of it are unclear and (b) an Execution Context is not currently a data type but will need further work, but it's a possibility. EDIT: Grammar. |
|
I don't see why this couldn't be done entirely within the agents proposal. Why does this concept need to be added before that proposal is integrated? |
|
@michaelficarra, sorry for not explaining that. The purpose is to get rid of the agents proposal by splitting it in two: this part as a PR - because it largely bundles up what is in E262 already, though some of it is unstated - and the other part goes back into the shared memory proposal. |
|
Oh, okay. Thanks for the explanation. |
| <p>An agent becomes <em>blocked</em> when its running execution context waits synchronously and indefinitely for an external event. Only agents whose Agent Record's [[CanBlock]] property is ~true~ can become blocked in this sense. An <em>unblocked</em> agent is one that is not blocked. </p> | ||
|
|
||
| <emu-note> | ||
| <p> The shared memory proposal introduces a memory for blocking in the Atomics.wait method. </p> |
There was a problem hiding this comment.
"method". Will fix.
| @@ -6284,7 +6284,7 @@ | |||
| <p>An agent becomes <em>blocked</em> when its running execution context waits synchronously and indefinitely for an external event. Only agents whose Agent Record's [[CanBlock]] property is ~true~ can become blocked in this sense. An <em>unblocked</em> agent is one that is not blocked. </p> | |||
|
|
|||
| <emu-note> | |||
| <p> The shared memory proposal introduces a memory for blocking in the Atomics.wait method. </p> | |||
| <p> The shared memory proposal introduces a method for blocking in the Atomics.wait method. </p> | |||
There was a problem hiding this comment.
Stylistically it's still a disaster, of course ("method ... method"). Sigh. Maybe a "means of blocking in the A.w method" would be better.
There was a problem hiding this comment.
Is the Atomics.wait method the way you block? "The shared memory proposal introduces the Atomics.wait method for blocking." It being inside the method seems a little odd.
|
ping @lars-t-hansen, have some review notes for you still. |
|
@bterlson, this was cleaned up as requested, any further remarks about it? |
|
Finally merging this. Looking forward to landing shared memory and atomics! |
|
Wohoo! |
This PR creates a minimal amount of infrastructure around executing "agents". Informally, agents are bundles of the existing execution machinery and a few additional bits.
The shared memory spec needs to talk about the relation between multiple executing agents at the semantic level. For example, some executing agents can enter a synchronous wait state by calling Atomics.wait, and other executing agents can wake waiting agents by calling Atomics.wake. It thus becomes necessary to treat agents as semantics objects. In addition, the shared memory spec will need to attach properties to agents, making it even more convenient for them to be semantic objects.
Finally, a notion of forward progress is introduced here. That notion is required for the shared memory work but it is also implicit in the existing ECMAScript spec: guarantees that exist (or don't) on forward progress of agents and their jobs. It is possible to formalize forward progress more than I've done here but it's not yet obvious that it's necessary to do so.
I'm presenting this as a PR since it really just bundles and formalizes existing machinery. The shared memory spec will build on what is introduced here.