JS interop should support threading

[lambdageek]

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

[ghost]

Tagging subscribers to this area: @mangod9
See info in area-owners.md if you want to be subscribed.

Issue Details

---

null

Author:	lambdageek
Assignees:	-
Labels:	area-System.Threading
Milestone:	-

[lambdageek]

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 AddProperty and LookupProperty are called from the same thread?

What if I'm in an async method?

What if I'm in a threadpool thread?

[lambdageek]

It seems like we want to focus on a couple of key scenarios to help us hone in on a good design.

For example:

1. "make fetch and C# HttpClient.GetAsync usable from any thread
2. "make it possible to load a JS library into a Web Worker and usable from a single (non-threadpool) Thread"
3. "make it possible to link the result of a JS call to a particular thread and make it possible to return to that thread for subsequent operations"

Some open questions:

• what should happen if a worker is reused for a new thread? Shoudl the JS libraries that were loaded before be unloaded somehow?
• What to do with JS libraries that expose "void void" functions that don't take any arguments or results but that need to be tied to a particular threads?
• Should we allow returning to the same threadpool thread? how - by installing a SynchronizationContext transparently? require the user to set things up explicitly?

[imoldfella]

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

[lambdageek]

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.

[imoldfella]

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?

[ghost]

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

---

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

Author:	lambdageek
Assignees:	-
Labels:	arch-wasm, area-System.Runtime.InteropServices.JavaScript, os-browser
Milestone:	8.0.0