Index: runtime/vm/thread_registry.h |
diff --git a/runtime/vm/thread_registry.h b/runtime/vm/thread_registry.h |
index 6c334634ca074fc6ff65de59ad03ec9b46f73383..3c232348f406d248e1fe67b21512428a36458369 100644 |
--- a/runtime/vm/thread_registry.h |
+++ b/runtime/vm/thread_registry.h |
@@ -73,11 +73,17 @@ class ThreadRegistry { |
Thread* free_list_; // Free list of Thread objects that can be reused. |
// TODO(asiva): Currently we treat a mutator thread as a special thread |
// and always schedule execution of Dart code on the same mutator thread |
- // object. This is because ApiState is still an object associated with |
- // the isolate and switching execution to another thread causes problems. |
- // Once ApiState is made a per Thread object it should be possible to |
- // free a mutator thread like all other threads and continue running on |
- // a different thread. |
+ // object. The ApiLocalScope has been made thread specific but we still |
+ // have scenarios where we do a temporary exit of an Isolate with live |
+ // zones/handles in the the API scope : |
+ // - Dart_RunLoop() |
+ // - IsolateSaver in Dart_NewNativePort |
+ // - Isolate spawn (function/uri) under FLAG_i_like_slow_isolate_spawn |
+ // We probably need a mechanism to return to the specific thread only |
+ // for these specific cases, we should also determine if we should allow |
zra
2015/11/25 17:36:56
cases. We
siva
2015/11/25 18:25:08
Done.
|
+ // the embedder to exit an isolate with live state in zones/handles in |
+ // which case a new API for returning to the specific thread needs to be |
+ // added. |
Thread* mutator_thread_; |
// Safepoint rendezvous state. |