Support asynchronuous spawnDomFunction.

tools/dom/src/native_DOMPublic.dart

Index: tools/dom/src/native_DOMPublic.dart
diff --git a/tools/dom/src/native_DOMPublic.dart b/tools/dom/src/native_DOMPublic.dart
index 3d224713feccb98ba0ba27a1dd58e577a4bffeeb..5044945387b2bc1a40465d218c35733f44ec656a 100644
--- a/tools/dom/src/native_DOMPublic.dart
+++ b/tools/dom/src/native_DOMPublic.dart
@@ -5,7 +5,17 @@
 part of html;
 
 // This API is exploratory.
-spawnDomFunction(Function topLevelFunction) => _Utils.spawnDomFunctionImpl(topLevelFunction);
+Future<SendPort> spawnDomFunction(Function topLevelFunction) {
+  final completer = new Completer<SendPort>();
+  final port = new ReceivePort();
+  port.receive((result, _) {
+    completer.complete(result);
+    port.close();
+  });
+  // TODO: SendPort.hashCode is ugly way to access port id.
+  _Utils.spawnDomFunction(topLevelFunction, port.toSendPort().hashCode);

[vsm, 2013/03/26 19:13:37]

Yuck...  Is a Handle -> Port API coming in the VM?  It'd be great to get rid of
this.

I also worry about security / calling _Utils.spawnDomFunction with an arbitrary
int.  Other libs *shouldn't* see it, but with mirrors etc., it seems like a
potential hole.

[Anton Muhin, 2013/03/26 19:15:37]

Absolutely w/ you here, I've already asked Siva to give a more direct access to
this stuff---it's only an ugly temporary measure.

On 2013/03/26 19:13:37, vsm wrote:

+  return completer.future;
+}
 
 // testRunner implementation.
 // FIXME: provide a separate lib for testRunner.