Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add language to define Agents #522

Merged
merged 4 commits into from Dec 20, 2016
Merged

Add language to define Agents #522

merged 4 commits into from Dec 20, 2016

Conversation

@lars-t-hansen
Copy link
Contributor

@lars-t-hansen lars-t-hansen commented Apr 6, 2016

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.

@ljharb
Copy link
Member

@ljharb ljharb commented Apr 6, 2016

How are Agents and Realms related? Does a different agent necessarily have a distinct Realm (even though an Agent might contain multiple Realms)?

@lars-t-hansen
Copy link
Contributor Author

@lars-t-hansen lars-t-hansen commented Apr 6, 2016

@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.

@michaelficarra
Copy link
Member

@michaelficarra michaelficarra commented Apr 6, 2016

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?

@lars-t-hansen
Copy link
Contributor Author

@lars-t-hansen lars-t-hansen commented Apr 6, 2016

@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.

@michaelficarra
Copy link
Member

@michaelficarra michaelficarra commented Apr 6, 2016

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>

This comment has been minimized.

@jmdyck

jmdyck Apr 6, 2016
Collaborator

"a memory for blocking"?

This comment has been minimized.

@lars-t-hansen

lars-t-hansen Apr 6, 2016
Author Contributor

"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>

This comment has been minimized.

@jmdyck

jmdyck Apr 6, 2016
Collaborator

Ah, thanks.

This comment has been minimized.

@lars-t-hansen

lars-t-hansen Apr 7, 2016
Author Contributor

Stylistically it's still a disaster, of course ("method ... method"). Sigh. Maybe a "means of blocking in the A.w method" would be better.

This comment has been minimized.

@annevk

annevk Apr 7, 2016
Member

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.

<emu-clause id="sec-agents">
<h1>Agents</h1>

<p> An <dfn id="agent">agent</dfn> comprises a set of ECMAScript execution contexts, an execution context stack, a running execution context, a set of named job queues, an <dfn id="agent-record">Agent Record</dfn>, and an <dfn id="executing-thread">executing thread</dfn>. Except for the executing thread, the constituents of an agent belong exclusively to that agent. </p>

This comment has been minimized.

@bterlson

bterlson Apr 7, 2016
Member

I think these IDs are superfluous - if omitted, inbound links hit the containing clause. At least agent can be omitted but I'd be fine with Agent Record and and executing thread referring to this clause.

This comment has been minimized.

@bterlson

bterlson Apr 7, 2016
Member

Eh on second thought you can keep these in if you like :-P I try to be conservative with making new IDs since each new one is a maintenance burden but these are unlikely to be problems.

This comment has been minimized.

@domenic

domenic Apr 7, 2016
Member

Yeah, I'd really prefer having ids on all dfns.


<p> An <dfn id="agent">agent</dfn> comprises a set of ECMAScript execution contexts, an execution context stack, a running execution context, a set of named job queues, an <dfn id="agent-record">Agent Record</dfn>, and an <dfn id="executing-thread">executing thread</dfn>. Except for the executing thread, the constituents of an agent belong exclusively to that agent. </p>

<p> An agent's executing thread executes the jobs in the agent's job queues on the agent's execution contexts independently of other agents, except that an executing thread may be used as the executing thread by multiple agents if none of the agents sharing the thread have an Agent Record whose [[CanBlock]] property that is ~true~. </p>

This comment has been minimized.

@bterlson

bterlson Apr 7, 2016
Member

Please remove the spaces inside various elements (here and a few places below).

<p> An agent's executing thread executes the jobs in the agent's job queues on the agent's execution contexts independently of other agents, except that an executing thread may be used as the executing thread by multiple agents if none of the agents sharing the thread have an Agent Record whose [[CanBlock]] property that is ~true~. </p>

<emu-note>
<p> Some web browsers share an executing thread across the documents of a browser window, for example. </p>

This comment has been minimized.

@bterlson

bterlson Apr 7, 2016
Member

This note is confusing to my read. Does it mean tabs of a browser window UI or document objects from various frames within a particular tab?

This comment has been minimized.

@lars-t-hansen

lars-t-hansen Jun 29, 2016
Author Contributor

I believe it can mean both, though what I intended was that different tabs in the same window can share the same executing thread. (They do in Firefox.)

</table>
</emu-table>

<p> An agent is a specification mechanism and need not correspond to any particular artefact of an ECMAScript implementation. </p>

This comment has been minimized.

@bterlson

bterlson Apr 7, 2016
Member

Probably could be a note.

<tr>
<td> [[LittleEndian]] </td>
<td> Boolean </td>
<td> The default value computed for the <em>isLittleEndian</em> parameter when it is needed by the algorithms GetValueFromBuffer and SetValueInBuffer. The choice is implementation dependent and should be the alternative that is most efficient for the implementation. Constant. </td>

This comment has been minimized.

@bterlson

bterlson Apr 7, 2016
Member

No other records indicate which of their fields is constant. I also worry that constant could be confusing without defining what it means in the context of a spec internal record. Maybe I'm being overly pedantic :-P

This comment has been minimized.

@lars-t-hansen

lars-t-hansen Jun 29, 2016
Author Contributor

Or maybe I'm being overly cautious. It's necessary for integrity that the field not take on more than one value at run-time (for the given agent). It's also clear from the spec text that nothing sets this field, but that doesn't really prevent the implementation from doing so, hence the "constant" annotation. But I will attempt to rephrase.

<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 method for blocking in the Atomics.wait method. </p>

This comment has been minimized.

@bterlson

bterlson Apr 7, 2016
Member

I think we can go ahead and link to it since its on the TC39 repo :)


<p>For an agent to <em>make forward progress</em> is for it to perform an evaluation step according to this specification.</p>

<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>

This comment has been minimized.

@bterlson

bterlson Apr 7, 2016
Member

ECMAScript values use *'s rather than 's ('s are for spec-level constants like Empty).

@bterlson
Copy link
Member

@bterlson bterlson commented May 6, 2016

ping @lars-t-hansen, have some review notes for you still.

@lars-t-hansen
Copy link
Contributor Author

@lars-t-hansen lars-t-hansen commented Jul 24, 2016

@bterlson, this was cleaned up as requested, any further remarks about it?

@bterlson bterlson merged commit 2e6a254 into tc39:master Dec 20, 2016
@bterlson
Copy link
Member

@bterlson bterlson commented Dec 20, 2016

Finally merging this. Looking forward to landing shared memory and atomics!

@lars-t-hansen
Copy link
Contributor Author

@lars-t-hansen lars-t-hansen commented Dec 20, 2016

Wohoo!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

7 participants