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

Conversation

Projects
None yet
7 participants
@lars-t-hansen
Contributor

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

This comment has been minimized.

Member

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

This comment has been minimized.

Contributor

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

This comment has been minimized.

Member

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

This comment has been minimized.

Contributor

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

This comment has been minimized.

Member

michaelficarra commented Apr 6, 2016

Oh, okay. Thanks for the explanation.

spec.html Outdated
<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

Contributor

"method". Will fix.

spec.html Outdated
@@ -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

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

Contributor

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.

spec.html Outdated
<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.

spec.html Outdated
<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).

spec.html Outdated
<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

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

spec.html Outdated
</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.

spec.html Outdated
<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

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.

spec.html Outdated
<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 :)

spec.html Outdated
<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

This comment has been minimized.

Member

bterlson commented May 6, 2016

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

@lars-t-hansen

This comment has been minimized.

Contributor

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

This comment has been minimized.

Member

bterlson commented Dec 20, 2016

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

@lars-t-hansen

This comment has been minimized.

Contributor

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