rmawatson
Thought on adding support for web-worker.
A somewhat related background issue: https://github.com/flutter/flutter/issues/33577
It strikes me that extending this plugin to support web-workers would be tidy solution for flutter application to offload concurrent work in a web setting.
API
spawn<T>(void entryPoint(T message), T message) → Future
Would kick off window.Worker()
controlPort ↔ SendPort
would return a port that proxies around MessageChannel()
kill() → void
would close() the channel and terminate() the worker.
Unfortunately pause() → void and resume() → void does not really map nicely to MessagePort().
NOTE: The may not work for service workers which can continue to execute after initiating code terminates.
Would appreciate any feedback about the above idea.. I happy to attempt an implementation if it's appears feasible.
@rayk No, it isn't feasible right now. The actual problem is with the very first line you mention, spawn(). The problem is that the new worker would immediately need to call back to Dart code, using the entryPoint. This function is practically the code of the isolate/worker itself: it will run whatever you initiate from this function. You write it in Dart, it gets compiled and passed to the isolate on mobile but on the web, even if it gets compiled to the very same JavaScript the web worker would need to use, it's not a separate JS that could be passed to the worker. And the worker can't just call back into our main JS code, that's strictly impossible in the browser.
Basically, while on the mobile the main app and the isolates are kept separate by the framework, both are compiled to the same codebase and it's therefore possible for the isolate to call the entry point. On the web, I can't see anything that would allow a package to provide this. The toolchain itself would need to allow this, basically by compiling the code of the isolate into a separate, standalone JS that can be imported by the worker. The Flutter devs have to provide this, there is no other way (unless, of course, you're ready to duplicate whatever you put into the isolate in JavaScript yourself, which is possible but goes against the actual need described here).
I've spent the last couple of days experimenting with this (see https://github.com/deakjahn/flutter_isolate_web) and while I'd very much like to be proven wrong, I don't think that will actually happen. :-) As you can see from that code, I build upon another package (isolate_handler) that happens to build on this one here and while I might be biased slightly in this decision (I'm the new maintainer of isolate_handler now), I actually think this decision is rather sound. What isolate_handler adds is (partly) an abstraction of the message sending, so that you don't have the tedium of setting it up every time you need to start an isolate. And it's exactly this messaging layer that makes it rather simple to abstract away the differences between how isolates and web workers communicate (basically the same, but the actual implementations, of course, do differ).
Thanks for the reply and the effort... Just looking at this for the last two minutes, it could helpful.. Certainly in simplify the message handling... I have perviously implemented all of this in JS and from memory the marshalling of messages back and forth was a pain. I shall have a play with flutter_isloate_web in the the next days and give you some feedback.
I'm currently using it in an app. The isolate part is older code, it works flawlessly. I also added an async implementation that implements the same interface, so it can be used as a drop-in replacement but it doesn't offer any real parallelism. This one works just fine in Flutter Web, too. This means that my current app is genuinely cross platform with the same isolate/worker code for all platforms, only that the web side doesn't yet enjoy the real benefits. Still, it works.