[Proxying] Add emscripten_proxy_callback_with_ctx

[tlively]

This new proxying function is like emscripten_proxy_callback, but supports
proxying of asynchronous work just like emscripten_proxy_sync_with_ctx. It
uses the existing em_proxying_ctx type and emscripten_proxy_finish function
to mark the work done, and that type and function are internally augmented to
handle both synchronous and callback-based proxying. emscripten_proxy_callback
is reimplemented to share most of its implementation with
emscripten_proxy_callback_with_ctx, but it does break the abstraction slightly
to avoid having to make an extra allocation.

[tlively]

Current dependencies on/for this PR:

• main
  • PR [Proxying][NFC] Move deferred cleanup logic to em_task_queue #18851
    • PR [Proxying] Send messages via in-memory mailbox queues #18852
      • PR [Proxying] Cancel proxied work when the worker thread dies #18741
        • PR [Proxying] Update proxying with callback to support cancellation #18776
          • PR [Proxying] Add emscripten_proxy_callback_with_ctx #18810 👈
            • PR [Proxying] Add proxying functions that return promises #18825
              • PR [Proxying] Use Atomics.waitAsync to receive proxying notifications #18861
                • PR Remove unnecessary EXIT_RUNTIME setting from proxying tests #18873

This comment was auto-generated by Graphite.

[tlively]

@sbc100 this is good to go besides review.

[sbc100]

lgtm % naming .. which we can bikeshed later.

[sbc100]

Should we just called this emscripten_proxy_async_with_ctx?

I think maybe the _with_callback distinction is important, and also obvious the from the args. Ideally I think we could remove the _with_callback variants that just have the normal versions take optional callbacks in all cases.

Another reason is that all the current function start with either emscripten_proxy_sync or emscripten_proxy_async

[tlively]

After this full sequence of PRs, we have :

emscripten_proxy_async
emscripten_proxy_sync{_with_ctx}
emscripten_proxy_callback{_with_ctx}
emscripten_proxy_promise{_with_ctx}

If we really wanted to minimize the API surface, my preference would be to remove emscripten_proxy_async and emscripten_proxy_callback*, leaving only sync and promise proxying, with and without ctxs. The reason I haven't tried to do that minimization yet is that it seems low cost to expose the extra functions if we're going to have nearly identical functions under the hood either way. Users get the most options at negligible maintenance cost to us.

[sbc100]

Sounds reasonable.

As a general rule, I would rather keep the low level C API as small as possible. For this kind of low level API (which I hope most users will never need to use), I think its fine if we don't include helpers/wrappers/shortcuts.

If we want to provide them in C++ API, or in a higher level set of C APIS, that would be fine, but at least for me it helper conceptually to keep this surface small... but maybe thats just me.

None of this has to block this change.. I don't think refactoring this layer later on is very risky.