Remove unused (and unusable) emscripten_sync_run_in_main_thread API.

[sbc100]

This family of function was not used anywhere and is not currently usable externally.

The core function emscripten_sync_run_in_main_thread was not usable since the its first argument is em_queued_call which is not struct that is declared externally.

The emscripten_sync_run_in_main_thread_N function takes a function enum as arg0 which is not designed to be user facing.

It looks like these function were once used by JS library code but the last remaining use of them was removed in #16405.

See: #15756

[juj]

The core function emscripten_sync_run_in_main_thread was not usable since the its first argument is em_queued_call which is not struct that is declared externally.

It looks like the earlier refactor brought on a regression to make that function not usable? This PR now makes that regression a design? ( #15756 (comment) )

In the other thread, there was a question

I'm a big fan of making the public API as small a possible. Is there a specific use case that emscripten_sync_run_in_main_thread enabled?

The main feature that creating em_queued_calls manually provided was the ability to make callee-free proxied calls, i.e. ones that had satellite data associated with them. This is the mechanism that off-thread proxied WebGL would use. I agree this API was never really documented well enough, but the idea was to allow users to reuse the same system API that already existed, to avoid having them to duplicate the same kind of feature in their own code. Of course given that this was not documented beyond the header files, then it is likely that not many people used the feature.

[sbc100]

The core function emscripten_sync_run_in_main_thread was not usable since the its first argument is em_queued_call which is not struct that is declared externally.

It looks like the earlier refactor brought on a regression to make that function not usable? This PR now makes that regression a design? ( #15756 (comment) )

Basically yes.

In the other thread, there was a question

I'm a big fan of making the public API as small a possible. Is there a specific use case that emscripten_sync_run_in_main_thread enabled?

The main feature that creating em_queued_calls manually provided was the ability to make callee-free proxied calls, i.e. ones that had satellite data associated with them. This is the mechanism that off-thread proxied WebGL would use. I agree this API was never really documented well enough, but the idea was to allow users to reuse the same system API that already existed, to avoid having them to duplicate the same kind of feature in their own code. Of course given that this was not documented beyond the header files, then it is likely that not many people used the feature.

Yes, unless there is some user out there who hasn't upgraded in over a year I think we can be fairly sure there are zero such users.

@tlively does your new proxying API have some way to cover the above use case of "callee-free proxied calls"?

[tlively]

@tlively does your new proxying API have some way to cover the above use case of "callee-free proxied calls"?

The proxy queue API is fully general, but only in the sense that it allows you to pass arbitrary void* data around. For the sake of keeping things simple and well-layered, it doesn't directly support the managed satellite data or dynamic signature typing that em_queued_call supports.

[sbc100]

OK, well I propose that we leave this change in place and we can resurrect this a user facing API if/when there is a demand for it.