-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
JS interop should support threading #76956
Comments
Tagging subscribers to this area: @mangod9 Issue Detailsnull
|
I think this is going to require some careful design work. Just thinking through how I would call 2 JS imports that share some JS state it seems like we will need some careful coordination - either transparent to the user (how?) Ie suppose I exposed a JS dictionary: [JSImport]
void AddProperty(string key, int val);
[JSImport]
int LookupProperty(string key); how would I guarantee that What if I'm in an async method? What if I'm in a threadpool thread? |
It seems like we want to focus on a couple of key scenarios to help us hone in on a good design. For example:
Some open questions:
|
Maybe one more question - what happens when initial webworker is terminated? are the workers being used for multithreading terminated immediately, or eventually, or never? https://html.spec.whatwg.org/multipage/workers.html#dom-worker-terminate-dev |
@imoldfella what do you mean by "initial webworker"? Right now our deployment model is to run the .NET main thread on the main browser thread. So if you navigate away from a page, for example, the main thread (and with it, all the underlying Emscripten infrastructure) will be gone. Any webworkers will be terminated (as you linked above), but even if they weren't they will probably fail ungracefully since so much of the Emscripten threading support relies on being able to communicate with the main browser thread. |
ah, thanks for pointing that out. Normally having webassembly in a worker is convenient because without threads it's difficult to cancel things other than with terminate, but what you described makes perfect sense. Should I be able to use a CancellationToken if I need to stop a task running on a worker thread? |
Tagging subscribers to 'arch-wasm': @lewing Issue DetailsJavaScript interop: JS object references in managed need to be tied to a thread - there's no shared JS memory with WebWorkers Tracking issue: #85592
|
JavaScript interop: JS object references in managed need to be tied to a thread - there's no shared JS memory with WebWorkers
Tracking issue: #85592
The text was updated successfully, but these errors were encountered: