[html5] r8336 - [giow] (0) Add a way to catch the other side of a port having a catastrophic dea [...]
whatwg at whatwg.org
whatwg at whatwg.org
Fri Dec 6 17:22:39 PST 2013
Author: ianh
Date: 2013-12-06 17:22:36 -0800 (Fri, 06 Dec 2013)
New Revision: 8336
Modified:
complete.html
index
source
Log:
[giow] (0) Add a way to catch the other side of a port having a catastrophic death.
Affected topics: DOM APIs
Modified: complete.html
===================================================================
--- complete.html 2013-12-06 19:31:38 UTC (rev 8335)
+++ complete.html 2013-12-07 01:22:36 UTC (rev 8336)
@@ -298,7 +298,7 @@
<header class=head id=head><p><a href=http://www.whatwg.org/ class=logo><img width=101 src=/images/logo alt=WHATWG height=101></a></p>
<hgroup><h1 class=allcaps>HTML</h1>
- <h2 class="no-num no-toc">Living Standard — Last Updated 6 December 2013</h2>
+ <h2 class="no-num no-toc">Living Standard — Last Updated 7 December 2013</h2>
</hgroup><dl><dt><strong>Web developer edition:</strong></dt>
<dd><strong><a href=http://developers.whatwg.org/>http://developers.whatwg.org/</a></strong></dd>
<dt>Multiple-page version:</dt>
@@ -80377,6 +80377,7 @@
// event handlers
attribute <a href=#eventhandler>EventHandler</a> <a href=#handler-messageport-onmessage title=handler-MessagePort-onmessage>onmessage</a>;
+ attribute <a href=#eventhandler>EventHandler</a> <a href=#handler-messageport-onerror title=handler-MessagePort-onerror>onerror</a>;
};
// <a href=#messageport>MessagePort</a> implements <a href=#transferable>Transferable</a>;</pre>
@@ -80739,6 +80740,33 @@
disentangle the two ports. If the method is called on a port that is not entangled, then the
method must do nothing.</p>
+ <hr><p>In some circumstances, an entangled <code><a href=#messageport>MessagePort</a></code> <var title="">source port</var>
+ that is not <a href=#ports-and-garbage-collection>eligible for garbage collection</a> will
+ nonetheless find itself prematurely destroyed, for example if the user manually terminates the
+ user agent's host process. Under such circumstances, user agents should attempt to following these
+ steps:</p>
+
+ <!-- don't fire this for navigation, it would break bfcache -->
+ <!-- for consistency, we don't fire this for worker termination -->
+ <!-- we don't fire it on .close() because that would let you probe GC behaviour also -->
+
+ <ol><li><p>Let <var title="">target port</var> be the port with which the ill-fated <var title="">source port</var> is entangled.</li>
+
+ <li><p>If there is no <var title="">target port</var> (i.e. if <var title="">source port</var>
+ is not entangled), or if <var title="">target port</var> is suffering the same fate as <var title="">source port</var> (e.g. if both ports are in the same host process), then abort these
+ steps.</li>
+
+ <li><p><a href=#queue-a-task>Queue a task</a> to <a href=#fire-a-simple-event>fire a simple event</a> named <code title=event-error>error</code> at <var title="">target port</var>. The <a href=#concept-task title=concept-task>task</a> must be associated with the <a href=#responsible-document>responsible document</a>
+ specified by <var title="">source port</var>'s <a href=#concept-port-owner title=concept-port-owner>owner</a>,
+ and must use the <a href=#dom-manipulation-task-source>DOM manipulation task source</a>.</li>
+
+ <li><p>Disentangle the two ports.</li>
+
+ </ol><p class=note>This does not happen if the port is garbage collected or closed using the <code title=dom-messageport-close><a href=#dom-messageport-close>close()</a></code> method. It is intended only as a way for Web
+ applications that operate across multiple browser processes (e.g. using workers or communicating
+ across multiple tabs) to gracefully handle a catastrophic failure in one process. A strictly
+ conforming user agent would never fail unexpectedly, and thus would never send this event!</p>
+
<hr><p>The following are the <a href=#event-handlers>event handlers</a> (and their corresponding <a href=#event-handler-event-type title="event
handler event type">event handler event types</a>) that must be supported, as <a href=#event-handler-idl-attributes>event
handler IDL attributes</a>, by all objects implementing the <code><a href=#messageport>MessagePort</a></code>
@@ -80746,6 +80774,7 @@
<table><thead><tr><th><a href=#event-handlers title="event handlers">Event handler</a> <th><a href=#event-handler-event-type>Event handler event type</a>
<tbody><tr><td><dfn id=handler-messageport-onmessage title=handler-MessagePort-onmessage><code>onmessage</code></dfn> <td> <code title=event-message><a href=#event-message>message</a></code>
+ <tr><td><dfn id=handler-messageport-onerror title=handler-MessagePort-onerror><code>onerror</code></dfn> <td> <code title=event-error>error</code>
</table><p>The first time a <code><a href=#messageport>MessagePort</a></code> object's <code title=handler-MessagePort-onmessage><a href=#handler-messageport-onmessage>onmessage</a></code> IDL attribute is set, the port's <a href=#port-message-queue>port
message queue</a> must be enabled, as if the <code title=dom-MessagePort-start><a href=#dom-messageport-start>start()</a></code>
method had been called.</p>
@@ -80877,12 +80906,13 @@
</div>
+<!--CLEANUP-->
<p>Furthermore, a <code><a href=#messageport>MessagePort</a></code> object must not be garbage collected while there exists
- a message in a <a href=#task-queue>task queue</a> that is to be dispatched on that <code><a href=#messageport>MessagePort</a></code>
- object, or while the <code><a href=#messageport>MessagePort</a></code> object's <a href=#port-message-queue>port message queue</a> is open and
+ an event in a <a href=#task-queue>task queue</a> that is to be dispatched on that <code><a href=#messageport>MessagePort</a></code>
+ object, or while the <code><a href=#messageport>MessagePort</a></code> object's <a href=#port-message-queue>port message queue</a> is enabled and
there exists a <code title=event-message><a href=#event-message>message</a></code> event in that queue.</p> <!-- we might
not need to explicitly say the first part if DOM Events is fixed to say that events on a task
- queue prevent GC -->
+ queue prevent GC, and the second part really is pretty redundant so maybe we don't need that either -->
<!-- ports in the ports attribute of a MessageEvent that isn't dispatched yet are safe because the
MessageEvent is safe -->
@@ -80897,7 +80927,8 @@
<p class=note>Authors are strongly encouraged to explicitly close <code><a href=#messageport>MessagePort</a></code>
objects to disentangle them, so that their resources can be recollected. Creating many
<code><a href=#messageport>MessagePort</a></code> objects and discarding them without closing them can lead to high
- transient memory usage since garbage collection is not necessarily performed promptly.</p>
+ transient memory usage since garbage collection is not necessarily performed promptly, especially
+ for <code><a href=#messageport>MessagePort</a></code>s where garbage collection can involve cross-process coordination.</p>
<!--POSTMSG-->
Modified: index
===================================================================
--- index 2013-12-06 19:31:38 UTC (rev 8335)
+++ index 2013-12-07 01:22:36 UTC (rev 8336)
@@ -298,7 +298,7 @@
<header class=head id=head><p><a href=http://www.whatwg.org/ class=logo><img width=101 src=/images/logo alt=WHATWG height=101></a></p>
<hgroup><h1 class=allcaps>HTML</h1>
- <h2 class="no-num no-toc">Living Standard — Last Updated 6 December 2013</h2>
+ <h2 class="no-num no-toc">Living Standard — Last Updated 7 December 2013</h2>
</hgroup><dl><dt><strong>Web developer edition:</strong></dt>
<dd><strong><a href=http://developers.whatwg.org/>http://developers.whatwg.org/</a></strong></dd>
<dt>Multiple-page version:</dt>
@@ -80377,6 +80377,7 @@
// event handlers
attribute <a href=#eventhandler>EventHandler</a> <a href=#handler-messageport-onmessage title=handler-MessagePort-onmessage>onmessage</a>;
+ attribute <a href=#eventhandler>EventHandler</a> <a href=#handler-messageport-onerror title=handler-MessagePort-onerror>onerror</a>;
};
// <a href=#messageport>MessagePort</a> implements <a href=#transferable>Transferable</a>;</pre>
@@ -80739,6 +80740,33 @@
disentangle the two ports. If the method is called on a port that is not entangled, then the
method must do nothing.</p>
+ <hr><p>In some circumstances, an entangled <code><a href=#messageport>MessagePort</a></code> <var title="">source port</var>
+ that is not <a href=#ports-and-garbage-collection>eligible for garbage collection</a> will
+ nonetheless find itself prematurely destroyed, for example if the user manually terminates the
+ user agent's host process. Under such circumstances, user agents should attempt to following these
+ steps:</p>
+
+ <!-- don't fire this for navigation, it would break bfcache -->
+ <!-- for consistency, we don't fire this for worker termination -->
+ <!-- we don't fire it on .close() because that would let you probe GC behaviour also -->
+
+ <ol><li><p>Let <var title="">target port</var> be the port with which the ill-fated <var title="">source port</var> is entangled.</li>
+
+ <li><p>If there is no <var title="">target port</var> (i.e. if <var title="">source port</var>
+ is not entangled), or if <var title="">target port</var> is suffering the same fate as <var title="">source port</var> (e.g. if both ports are in the same host process), then abort these
+ steps.</li>
+
+ <li><p><a href=#queue-a-task>Queue a task</a> to <a href=#fire-a-simple-event>fire a simple event</a> named <code title=event-error>error</code> at <var title="">target port</var>. The <a href=#concept-task title=concept-task>task</a> must be associated with the <a href=#responsible-document>responsible document</a>
+ specified by <var title="">source port</var>'s <a href=#concept-port-owner title=concept-port-owner>owner</a>,
+ and must use the <a href=#dom-manipulation-task-source>DOM manipulation task source</a>.</li>
+
+ <li><p>Disentangle the two ports.</li>
+
+ </ol><p class=note>This does not happen if the port is garbage collected or closed using the <code title=dom-messageport-close><a href=#dom-messageport-close>close()</a></code> method. It is intended only as a way for Web
+ applications that operate across multiple browser processes (e.g. using workers or communicating
+ across multiple tabs) to gracefully handle a catastrophic failure in one process. A strictly
+ conforming user agent would never fail unexpectedly, and thus would never send this event!</p>
+
<hr><p>The following are the <a href=#event-handlers>event handlers</a> (and their corresponding <a href=#event-handler-event-type title="event
handler event type">event handler event types</a>) that must be supported, as <a href=#event-handler-idl-attributes>event
handler IDL attributes</a>, by all objects implementing the <code><a href=#messageport>MessagePort</a></code>
@@ -80746,6 +80774,7 @@
<table><thead><tr><th><a href=#event-handlers title="event handlers">Event handler</a> <th><a href=#event-handler-event-type>Event handler event type</a>
<tbody><tr><td><dfn id=handler-messageport-onmessage title=handler-MessagePort-onmessage><code>onmessage</code></dfn> <td> <code title=event-message><a href=#event-message>message</a></code>
+ <tr><td><dfn id=handler-messageport-onerror title=handler-MessagePort-onerror><code>onerror</code></dfn> <td> <code title=event-error>error</code>
</table><p>The first time a <code><a href=#messageport>MessagePort</a></code> object's <code title=handler-MessagePort-onmessage><a href=#handler-messageport-onmessage>onmessage</a></code> IDL attribute is set, the port's <a href=#port-message-queue>port
message queue</a> must be enabled, as if the <code title=dom-MessagePort-start><a href=#dom-messageport-start>start()</a></code>
method had been called.</p>
@@ -80877,12 +80906,13 @@
</div>
+<!--CLEANUP-->
<p>Furthermore, a <code><a href=#messageport>MessagePort</a></code> object must not be garbage collected while there exists
- a message in a <a href=#task-queue>task queue</a> that is to be dispatched on that <code><a href=#messageport>MessagePort</a></code>
- object, or while the <code><a href=#messageport>MessagePort</a></code> object's <a href=#port-message-queue>port message queue</a> is open and
+ an event in a <a href=#task-queue>task queue</a> that is to be dispatched on that <code><a href=#messageport>MessagePort</a></code>
+ object, or while the <code><a href=#messageport>MessagePort</a></code> object's <a href=#port-message-queue>port message queue</a> is enabled and
there exists a <code title=event-message><a href=#event-message>message</a></code> event in that queue.</p> <!-- we might
not need to explicitly say the first part if DOM Events is fixed to say that events on a task
- queue prevent GC -->
+ queue prevent GC, and the second part really is pretty redundant so maybe we don't need that either -->
<!-- ports in the ports attribute of a MessageEvent that isn't dispatched yet are safe because the
MessageEvent is safe -->
@@ -80897,7 +80927,8 @@
<p class=note>Authors are strongly encouraged to explicitly close <code><a href=#messageport>MessagePort</a></code>
objects to disentangle them, so that their resources can be recollected. Creating many
<code><a href=#messageport>MessagePort</a></code> objects and discarding them without closing them can lead to high
- transient memory usage since garbage collection is not necessarily performed promptly.</p>
+ transient memory usage since garbage collection is not necessarily performed promptly, especially
+ for <code><a href=#messageport>MessagePort</a></code>s where garbage collection can involve cross-process coordination.</p>
<!--POSTMSG-->
Modified: source
===================================================================
--- source 2013-12-06 19:31:38 UTC (rev 8335)
+++ source 2013-12-07 01:22:36 UTC (rev 8336)
@@ -90077,6 +90077,7 @@
// event handlers
attribute <span>EventHandler</span> <span data-x="handler-MessagePort-onmessage">onmessage</span>;
+ attribute <span>EventHandler</span> <span data-x="handler-MessagePort-onerror">onerror</span>;
};
// <span>MessagePort</span> implements <span>Transferable</span>;</pre>
@@ -90490,6 +90491,44 @@
<hr>
+ <p>In some circumstances, an entangled <code>MessagePort</code> <var data-x="">source port</var>
+ that is not <a href="#ports-and-garbage-collection">eligible for garbage collection</a> will
+ nonetheless find itself prematurely destroyed, for example if the user manually terminates the
+ user agent's host process. Under such circumstances, user agents should attempt to following these
+ steps:</p>
+
+ <!-- don't fire this for navigation, it would break bfcache -->
+ <!-- for consistency, we don't fire this for worker termination -->
+ <!-- we don't fire it on .close() because that would let you probe GC behaviour also -->
+
+ <ol>
+
+ <li><p>Let <var data-x="">target port</var> be the port with which the ill-fated <var
+ data-x="">source port</var> is entangled.</p></li>
+
+ <li><p>If there is no <var data-x="">target port</var> (i.e. if <var data-x="">source port</var>
+ is not entangled), or if <var data-x="">target port</var> is suffering the same fate as <var
+ data-x="">source port</var> (e.g. if both ports are in the same host process), then abort these
+ steps.</p></li>
+
+ <li><p><span>Queue a task</span> to <span>fire a simple event</span> named <code
+ data-x="event-error">error</code> at <var data-x="">target port</var>. The <span
+ data-x="concept-task">task</span> must be associated with the <span>responsible document</span>
+ specified by <var data-x="">source port</var>'s <span data-x="concept-port-owner">owner</span>,
+ and must use the <span>DOM manipulation task source</span>.</p></li>
+
+ <li><p>Disentangle the two ports.</p></li>
+
+ </ol>
+
+ <p class="note">This does not happen if the port is garbage collected or closed using the <code
+ data-x="dom-messageport-close">close()</code> method. It is intended only as a way for Web
+ applications that operate across multiple browser processes (e.g. using workers or communicating
+ across multiple tabs) to gracefully handle a catastrophic failure in one process. A strictly
+ conforming user agent would never fail unexpectedly, and thus would never send this event!</p>
+
+ <hr>
+
<p>The following are the <span>event handlers</span> (and their corresponding <span data-x="event
handler event type">event handler event types</span>) that must be supported, as <span>event
handler IDL attributes</span>, by all objects implementing the <code>MessagePort</code>
@@ -90500,6 +90539,7 @@
<tr><th><span data-x="event handlers">Event handler</span> <th><span>Event handler event type</span>
<tbody>
<tr><td><dfn data-x="handler-MessagePort-onmessage"><code>onmessage</code></dfn> <td> <code data-x="event-message">message</code>
+ <tr><td><dfn data-x="handler-MessagePort-onerror"><code>onerror</code></dfn> <td> <code data-x="event-error">error</code>
</table>
<p>The first time a <code>MessagePort</code> object's <code
@@ -90622,7 +90662,7 @@
</div>
- <h4>Ports and garbage collection</h4>
+ <h4 id="ports-and-garbage-collection">Ports and garbage collection</h4>
<div class="impl">
@@ -90643,12 +90683,13 @@
</div>
+<!--CLEANUP-->
<p>Furthermore, a <code>MessagePort</code> object must not be garbage collected while there exists
- a message in a <span>task queue</span> that is to be dispatched on that <code>MessagePort</code>
- object, or while the <code>MessagePort</code> object's <span>port message queue</span> is open and
+ an event in a <span>task queue</span> that is to be dispatched on that <code>MessagePort</code>
+ object, or while the <code>MessagePort</code> object's <span>port message queue</span> is enabled and
there exists a <code data-x="event-message">message</code> event in that queue.</p> <!-- we might
not need to explicitly say the first part if DOM Events is fixed to say that events on a task
- queue prevent GC -->
+ queue prevent GC, and the second part really is pretty redundant so maybe we don't need that either -->
<!-- ports in the ports attribute of a MessageEvent that isn't dispatched yet are safe because the
MessageEvent is safe -->
@@ -90663,7 +90704,8 @@
<p class="note">Authors are strongly encouraged to explicitly close <code>MessagePort</code>
objects to disentangle them, so that their resources can be recollected. Creating many
<code>MessagePort</code> objects and discarding them without closing them can lead to high
- transient memory usage since garbage collection is not necessarily performed promptly.</p>
+ transient memory usage since garbage collection is not necessarily performed promptly, especially
+ for <code>MessagePort</code>s where garbage collection can involve cross-process coordination.</p>
<!--END postmsg--><!--POSTMSG-->
More information about the Commit-Watchers
mailing list