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
isolates API change: spawn functions should return a Future<SendPort> #4329
Comments
Added Library-Isolates label. |
Removed Isolates label. |
If we even have a standard way of spawning remote isolates this will likely be a problem there as well. Such a spawnRemote() function will certainly have to return a Future. |
Set owner to @justinfagnani. |
Added Library-Isolate label. |
Removed Library-Isolates label. |
Removed this from the 1.6 milestone. |
Removed Oldschool-Milestone-1.6 label. |
Added AssumedStale label. |
We discussed this long time ago, but I don't believe we wrote a bug for it.
Short story:
Currently [spawnFunction] returns a [SendPort], and we should change it to return a [Future<SendPort>].
Long story:
In dart2js we can't resolve the port synchronously when this is implemented on top of web workers. We got a long-way with the current API by creating a buffering port. This is a port that buffers sent messages until the underlying port gets resolved (creating the illusion that the port is available synchronously).
This trick meant works great while you only send messages from that port. The problem is once you try to serialize that send port and sending it over a different port. At that point, we can no longer preserve the ordering guarantees unless we 'block' the other port.
It seems that at this point the system grows to be too complex.
The text was updated successfully, but these errors were encountered: