Convert most of the javascript isolate code into Dart, inject JS code only when

frog/value.dart

 // Copyright (c) 2011, the Dart project authors.  Please see the AUTHORS file
 // for details. All rights reserved. Use of this source code is governed by a
 // BSD-style license that can be found in the LICENSE file.
 
 /**
  * Represents a meta-value for code generation.
  */
 class Value {
   /** The [Type] of the [Value]. */
   Type type;
@@ skipping 225 matching lines @@
     if (callMethod != null) {
       if (checked && !toType.isAssignable(type)) {
         convertWarning(toType, node);
       }
 
       int arity = callMethod.parameters.length;
       var myCall = type.getCallMethod();
       if (myCall == null || myCall.parameters.length != arity) {
         final stub = world.functionType.getCallStub(new Arguments.bare(arity));
         var val = new Value(toType, 'to\$${stub.name}($code)', node.span);
+        // TODO(sigmund): try to remove, see below
         return _isDomCallback(toType) && !_isDomCallback(type) ?
             val._wrapDomCallback(toType, arity) : val;
       } else if (_isDomCallback(toType) && !_isDomCallback(type)) {
+        // TODO(sigmund): try to remove, see below
         return _wrapDomCallback(toType, arity);
       }
     }
 
     // If we're assigning from a var, pretend it's Object for the purpose of
     // runtime checks.
 
     // TODO(jmesserly): I'm a little bothered by the fact that we can't call
     // isSubtypeOf directly. If we tracked null literals as the bottom type,
     // and then only allowed Dynamic to be bottom for generic type args, I think
@@ skipping 17 matching lines @@
     }
 
     // Generate a runtime checks if they're turned on, otherwise skip it.
     if (options.enableTypeChecks) {
       return _typeAssert(context, toType, node);
     } else {
       return this;
     }
   }
 
+  /**
+   * Checks whether [toType] is a callback function, and it is defined in the
+   * dom library.
+   */
   bool _isDomCallback(toType) {
     return (toType.definition is FunctionTypeDefinition
         && toType.library == world.dom);
   }
 
+  /**
+   * Wraps a callback attached to the dom (e.g. event listeners, setTimeout) so
+   * we can restore it's isolate context information. This is needed so that
+   * callbacks are executed withing the context of the isolate that created them

[jimhug, 2011/11/16 18:00:45]

Nit: within

[Siggi Cherem (dart-lang), 2011/11/17 16:50:11]

Done.

+   * in the first place.
+   */
+  // TODO(sigmund): try to remove this specialized logic about isolates
+  // and the dom from the compiler, move into the actual dom library if
+  // possible.

[Jennifer Messerly, 2011/11/17 02:28:11]

I still don't think this is special logic. :)

All native libraries with callbacks--including node.js--will need to be isolate
aware. It is a fundamental property of implementing Dart isolates on top of a
non-isolate-aware JS runtime. And isolates are a big feature of Dart, so having
the compiler know about them is not a bad thing!

That said--it would be nice to make this more general and not DOM specific. 

What I'd like to see happen: we wrap any "native" callback automatically. The
trick is we need a way to not wrap for cases like List.sort, where we know that
the list function isn't going to call back to us from a different isolate. So we
need a way to mark the callback parameter as being same-isolate vs
different-isolate. (It'd be really nice to have more metadata in our "native"
keyword)

[Siggi Cherem (dart-lang), 2011/11/17 16:50:11]

totally agree. Although I would be quite happy if we can implement isolates
without the need of wrapping - I'm exploring one implementation of this, but I
still need to measure its performance implications.

   Value _wrapDomCallback(Type toType, int arity) {
+    if (arity == 0) {
+      world.gen.corejs.useWrap0 = true;

[Jennifer Messerly, 2011/11/17 02:28:11]

should this also set useIsolates to true? Or you could end up emitting a call to
$wrap_call$1, but not emitting the function, if I'm reading it right

[Siggi Cherem (dart-lang), 2011/11/17 16:50:11]

In this case no, we don't want to mark useIsolates=true to avoid introducing the
isolate code only because you use a callback in the dom. 

Instead, corejs.dart generates code whenever useWrap0 is true. If
useIsolates=false then the $wrap_call$0 body is just the identity function.

[Jennifer Messerly, 2011/11/17 19:18:03]

My bad. I didn't read corejs.dart carefully enough. I really like the approach
you took with this!

+    } else {
+      world.gen.corejs.useWrap1 = true;
+    }
     return new Value(toType, '\$wrap_call\$$arity($code)', span);
   }
 
   /**
    * Generates a run time type assertion for the given value. This works like
    * [instanceOf], but it allows null since Dart types are nullable.
    * Also it will throw a TypeError if it gets the wrong type.
    */
   Value _typeAssert(MethodGenerator context, Type toType, Node node) {
     if (toType is ParameterType) {
@@ skipping 372 matching lines @@
 
     // Then look for members in my library.
     member = home.library.lookup(name, span);
     if (member != null) {
       return member;
     }
 
     return null;
   }
 }