[Proxying] Add emscripten_proxy_callback_with_ctx - #18810
Conversation
|
Current dependencies on/for this PR:
This comment was auto-generated by Graphite. |
848ee7d to
2213f1a
Compare
1fe81f5 to
4baabe9
Compare
2213f1a to
8b7eadf
Compare
4baabe9 to
6a5e4e7
Compare
8b7eadf to
d67be45
Compare
6a5e4e7 to
5cb7113
Compare
d67be45 to
aaa19c3
Compare
5cb7113 to
da1f95e
Compare
da1f95e to
289203e
Compare
a1353b4 to
a5b591a
Compare
289203e to
2ef3195
Compare
a5b591a to
32309a3
Compare
2ef3195 to
4ccf2ee
Compare
32309a3 to
26bcd74
Compare
4ccf2ee to
1f0ecb4
Compare
26bcd74 to
413728b
Compare
1f0ecb4 to
af490a7
Compare
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.
af490a7 to
5415a72
Compare
|
@sbc100 this is good to go besides review. |
sbc100
left a comment
There was a problem hiding this comment.
lgtm % naming .. which we can bikeshed later.
| // `cancel` will be proxied back instead. All three function will receive the | ||
| // same argument, `arg`. Returns 1 if `func` was successfully enqueued and the | ||
| // target thread notified or 0 otherwise. | ||
| int emscripten_proxy_callback_with_ctx(em_proxying_queue* q, |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
…18810) 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.
…18810) 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.
This new proxying function is like
emscripten_proxy_callback, but supportsproxying of asynchronous work just like
emscripten_proxy_sync_with_ctx. Ituses the existing
em_proxying_ctxtype andemscripten_proxy_finishfunctionto mark the work done, and that type and function are internally augmented to
handle both synchronous and callback-based proxying.
emscripten_proxy_callbackis reimplemented to share most of its implementation with
emscripten_proxy_callback_with_ctx, but it does break the abstraction slightlyto avoid having to make an extra allocation.