[browser][MT] Keep track of additional JS keepalive sources for worker threads #85052
Comments
lambdageek
added
arch-wasm
ghost
added
the
|
Tagging subscribers to 'arch-wasm': @lewing Issue DetailsIn #84492 we added There could be, however, other reasons why a threadpool worker thread may need to stay alive: if the JS code has used
|
And link to dotnet#85052 for more details
|
/cc @pavelsavara |
This is part of #84489 - landing support for async JS interop on threadpool threads in multi-threaded WebAssembly. Provides two pieces of functionality: 1. A keepalive token that can be used to prevent the current POSIX thread from terminating when it returns from its thread start function, or from an invocation from the JS event loop. When the last keepalive token is destroyed (assuming Emscripten isn't keeping the thread alive for other reasons) it will terminate as if by calling `pthread_exit` and the webworker will be made available to other threads 2. A `HasUnsettledInteropPromises` property that peeks `_js_owned_object_table` to see if there are any promises created by the interop subsystem that have not been fulfilled or rejected yet. * [mono] add internal WebWorkerEventLoop utility class Provides two pieces of functionality: 1. A keepalive token that can be used to prevent the current POSIX thread from terminating when it returns from its thread start function, or from an invocation from the JS event loop. When the last keepalive token is destroyed (assuming Emscripten isn't keeping the thread alive for other reasons) it will terminate as if by calling `pthread_exit` and the webworker will be made available to other threads 2. A `HasUnsettledInteropPromises` property that peeks `_js_owned_object_table` to see if there are any promises created by the interop subsystem that have not been fulfilled or rejected yet. * Use a per-thread unsettled promise count for mono_wasm_eventloop_has_unsettled_interop_promises we can't use the _js_owned_object_table size because it contains other interop objects, not just promises * remove old emscripten keepalive workaround hack * Add a more general getter for JS interop to keep a webworker alive And link to #85052 for more details * fixup docs
|
I think we will solve this by not allowing JS interop from managed thread pool. Eventually by dispatching the JS calls to original web worker or UI thread. And possibly by explicit API for creating |
pavelsavara
changed the title
dotnet-policy-service
bot
added
the
in-pr
In #84492 we added
WebWorkerEventLoop.HasUnsettledInteropPromisesthat will be used by #84494 to keep a threadpool worker thread alive in the JS event loop as long as some promise exists that is needed by aJSImportedTaskin C#.There could be, however, other reasons why a threadpool worker thread may need to stay alive: if the JS code has used
setTimeoutwith a callback that depends on a JS proxy of a C# function or object, for example. These additional scenarios can be somewhat covered by creating promises that the C# code couldawait, but we should also have more robust tracking in our interop layer.The text was updated successfully, but these errors were encountered: