provide API for spawning DOM isolates

[sigmundch]

As we migrate to the new isolate's API, it's unclear what is the best API for spawning DOM isolates.

We used to have [window.spawnDOMIsolate] in dartium that takes as an argument a function to run. However, this is not that valuable use of isolates. More precisely, isolates have 2 main uses: concurrency and running untrusted third-party code. Under the new API we use [spawnFunction] for the former, and [spawnUri] for the latter.

When using DOM isolates, all isolates run in the UI-thread, so there is no concurrency win. We'd mostly want to use isolates in the same way as spawnUri.

We propose removing [spawnDOMIsolate], and instead, provide a function similar to spawnUri, that spawns the isolate in the UI thread (e.g. using iframes).

[DartBot]

This comment was originally written by @pjako

---

Let me get that right, the domisoltes are the isolates that still have limited access to the dom (see: https://developer.mozilla.org/en/DOM/Worker/Functions_available_to_workers) or have dom isolates full access to the dom?

Now the plan is that we have to use spawnUri to spawn new domisolates wouldn't that force us to send only strings instead of any type of object? (see: http://www.dartlang.org/docs/language-tour/#send-any-type-of-object)

[sigmundch]

Good question. We also need to figure that out. One idea was to have 3 spawning functions for the dom:

• spawnFunctionInWorker - like today's spawnFunction in the vm but also give it access to the worker APIs
• spawnUriInWorker - that spawns a URL in a worker
• spawnUriInIframe - spawns an isolate with access to also the DOM node tree.

[DartBot]

This comment was originally written by @pjako

---

That sounds quite good, however why should we have an special call "spawnFunctionInWorker()" instead of the normal call you have on the server "spawnFunction()" why would anyone brother to have something else on a dartium client then a worker isolate when spawnFunctionInWorker is used?

[DartBot]

This comment was originally written by @pjako

---

Sorry I meant:
Why would anyone brother to have something else on a dartium client, then a worker isolate when you spawn it from a function?

[DartBot]

This comment was originally written by [email protected]

---

p4jako,

workers are intentionally heavy-weight (at least the last time I looked into the spec) while we expect Dart isolates be very very lightweight.

So honestly I don't know the right answer for workers vs. Dart isolates for the given question. Having too APIs looks bad too. My immediate stance would be:

let's keep simple Dart isolates which know nothing of Worker API.
let's support DOM worker API (maybe w/ minimal sugar for starting.)

spawnUriInWindow(Window window, String/Uri uri) looks great for me.

[DartBot]

This comment was originally written by @pjako

---

My concern is mainly being able to send any type of object to workers(/isolates).
However, workers do have more a concept like spawnUri where you can only send Strings. So a spawnWorkerIsolateFromFuction would be nice, also to keep the communication api unified (so you can always work with isolates and dont have to brother with the dom worker api)

[DartBot]

This comment was originally written by @seaneagan

---

in that case, would probably want to make it an instance method:

interface Window {
  //...
  spawnUri(String uri);
}

[sigmundch]

Added Library-Isolates label.

[sigmundch]

Removed Isolates label.

[dgrove]

Added Library-Isolate label.

[dgrove]

Removed Library-Isolates label.

[lrhn]

I think a spawnDomIsolate (or whatever name) should be in dart:html, not dart:isolate, since dart:isolate must work outside the browser too.

It should have the same arguments and behavior as Isolate.spawnUri/Isolate.spawnUri, it just allows importing and using "dart:html".

---

Removed Library-Isolate label.
Added Library-Html label.

[DartBot]

This comment was originally written by [email protected]

---

Not sure if this directly related or should be a separate issue but could you just allow Websocket (which is part of dart:html) to be used in Isolate (browser isolate, so with webworker) ?
It's something we can already do with most browsers and javascript but not with Dart: we get an error 'DOM access is not enabled in this isolate'.

[alan-knight]

Removed Type-Defect label.
Added Type-Enhancement label.

[alan-knight]

Re #­14. We can't "just" do that, but we might do it.

One issue is that Dartium doesn't spawn workers in the background, it spawns dart isolates, so they have no context at all. That might be https://code.google.com/p/dart/issues/detail?id=21573 , but might be another bug as well.

Even if it's a worker, that has a limited API that isn't the same as dart:html exposes. The fact that it works in dartj2s is a bit of a coincidence in that the APIs are the same and it doesn't rely on anything missing. In Dartium it would be more complicated, because we're going through C++ bindings. Relying on it failing in an acceptable way if you call an unavailable API is less of an option in C++. Splitting out a dart:websocket would be one option.

However, if we have a worker, then it would at least be possible to call WebSocket APIs through JS interop as a workaround.

I'm going to split off the websocket issue as https://code.google.com/p/dart/issues/detail?id=22128

[DartBot]

This comment was originally written by @pjako

---

But it is not just websockets.. as I stated two years ago:

• HttpRequests (maybe a good moment to abstract this for darvm/dartium/dartisolate)
• async/sync IndexedDB
• spawn webworker (that may contain javascript)

[kevmoo]

Not worried about Isolate API and the Web any more - https://groups.google.com/a/dartlang.org/forum/#!topic/announce/jh8uN5S0GE4