[mono] add internal WebWorkerEventLoop utility class

[lambdageek]

This is Part 3 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.

[ghost]

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

Issue Details

---

This is Part 3 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.

Note that this has a soft dependency on #83998 - without the emscripten bump, emscripten_runtime_keepalive_push does not work correctly with our compilation options. As a result there's MONO_EMSCRIPTEN_KEEPALIVE_WORKAROUND_HACK which kind of attempts to work around the issue, but is imprecise and ideally we won't ship it.

Author:	lambdageek
Assignees:	lambdageek
Labels:	arch-wasm, area-Threading-mono
Milestone:	-

[lambdageek]

@pavelsavara anything else I should address in this one?

[pavelsavara]

I'm ok about the code, but I don't understand the big picture.
I guess this PR doesn't have usage of WebWorkerEventLoop in it and it would be in the follow-up PR part 4 ?
Why is the KeepaliveToken instance or multiple instances. Would simple counter suffice ?

[lambdageek]

I'm ok about the code, but I don't understand the big picture. I guess this PR doesn't have usage of
WebWorkerEventLoop in it and it would be in the follow-up PR part 4 ?

Yea it's used in the Part 4.

Why is the KeepaliveToken instance or multiple instances. Would simple counter suffice ?

I wanted to make something that is harder to misuse than the emscripten push/pop API. Also to mirror the JS setTimeout/clearTimeout API - so every caller will get a unique keepalive token. I kind of suspect this will eventually become a public API

What I like about the KeepaliveToken approach is that in async code it's too easy to call pop too many times (or zero times). With a KeepaliveToken you'll get an InvalidOperationException if you pop too many times, instead of an incorrect counter value.

[pavelsavara]

Thanks for explanation.
I see how this is useful, assuming there would be more than one push/pop per worker and that from external code.

I kind of suspect this will eventually become a public API

I'm not convinced this should be public API. Once we have use case for it we could re-consider it. For now, LGTM

[lambdageek]

WBT failure is #85010 (which needs a dotnet/sdk fix to flow down)

[lambdageek]

debugger test timeout is #84101