Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

provide API for spawning DOM isolates #3050

Closed
sigmundch opened this issue May 14, 2012 · 17 comments
Closed

provide API for spawning DOM isolates #3050

sigmundch opened this issue May 14, 2012 · 17 comments
Labels
area-library library-html P2 A bug or feature request we're likely to work on type-enhancement A request for a change that isn't a bug

Comments

@sigmundch
Copy link
Member

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
Copy link

DartBot commented May 14, 2012

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
Copy link
Member Author

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
Copy link

DartBot commented May 15, 2012

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
Copy link

DartBot commented May 15, 2012

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
Copy link

DartBot commented May 15, 2012

This comment was originally written by antonm@google.com


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
Copy link

DartBot commented May 15, 2012

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
Copy link

DartBot commented May 15, 2012

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
Copy link
Member Author

Added Library-Isolates label.

@sigmundch
Copy link
Member Author

Removed Isolates label.

@dgrove
Copy link
Contributor

dgrove commented Jan 11, 2013

Added Library-Isolate label.

@dgrove
Copy link
Contributor

dgrove commented Jan 11, 2013

Removed Library-Isolates label.

@lrhn
Copy link
Member

lrhn commented Oct 6, 2014

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
Copy link

DartBot commented Oct 8, 2014

This comment was originally written by kg...@hotmail.com


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
Copy link
Contributor

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

@alan-knight
Copy link
Contributor

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
Copy link

DartBot commented Jan 22, 2015

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 kevmoo added P2 A bug or feature request we're likely to work on type-enhancement A request for a change that isn't a bug and removed triaged labels Feb 29, 2016
@kevmoo
Copy link
Member

kevmoo commented Feb 24, 2018

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

@kevmoo kevmoo closed this as completed Feb 24, 2018
dart-bot pushed a commit that referenced this issue Aug 10, 2021
Bump pub

```
> git log --format="%C(auto) %h %s" 70b1a4f9229a36bac6340ec7eae2b2068baac96c..9f2ddc02f066c68fb638ff65fbb73761ece23267
 9f2ddc02 Use uris for paths in git source descriptions (#3063)
 97a0033e Update README.md (#3069)
 2ef10adf Roll setup-dart (#3054)
 4b5450d3 Updated repository specification. (#3050)
 0f3055db Add executables to allErrors (#3048)
```

Change-Id: Iaa42df2339b6f62aeb63e0f2e7eaf062da84e7c6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/209681
Reviewed-by: Jonas Jensen <jonasfj@google.com>
Commit-Queue: Sigurd Meldgaard <sigurdm@google.com>
copybara-service bot pushed a commit that referenced this issue May 24, 2022
…3 revisions)

https://dart.googlesource.com/dartdoc/+log/c58f21042ebd..8549817bb1b5

2022-05-24 49699333+dependabot[bot]@users.noreply.github.com Bump actions/checkout from 3 to 3.0.2 (#3048)
2022-05-24 49699333+dependabot[bot]@users.noreply.github.com Bump github/codeql-action from 1.0.26 to 2.1.11 (#3049)
2022-05-24 49699333+dependabot[bot]@users.noreply.github.com Bump actions/upload-artifact from 3.0.0 to 3.1.0 (#3050)

If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/dart-doc-dart-sdk
Please CC dart-ecosystem-gardener@grotations.appspotmail.com on the revert to ensure that a human
is aware of the problem.

To file a bug in Dart Documentation Generator: https://github.com/dart-lang/dartdoc/issues
To file a bug in Dart SDK: https://github.com/dart-lang/sdk/issues

To report a problem with the AutoRoller itself, please file a bug:
https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug

Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md

Tbr: dart-ecosystem-gardener@grotations.appspotmail.com
Change-Id: I14041ce5576cc0efadcc897603f8b7893b891b22
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/245721
Reviewed-by: Kevin Moore <kevmoo@google.com>
Commit-Queue: DEPS Autoroller <dart-autoroll@skia-public.iam.gserviceaccount.com>
Commit-Queue: Kevin Moore <kevmoo@google.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-library library-html P2 A bug or feature request we're likely to work on type-enhancement A request for a change that isn't a bug
Projects
None yet
Development

No branches or pull requests

6 participants