emscripten icon indicating copy to clipboard operation
emscripten copied to clipboard

Can we deprecate `--proxy-to-worker` / `-sPROXY_TO_WORKER`?

Open sbc100 opened this issue 3 months ago • 6 comments

I don't think they are going to be many folks using this.

IIUC it was mostly and experiment from the early days of emscripten to try to get synchronous applications running in a worker. However, since it always takes over the whole browser window I can't imagine many folks actually using it.

The process for deprecating and removing features from emscripten is laid out out in https://github.com/emscripten-core/emscripten/blob/main/docs/process.md#deprecating-settings-and-features).

At any point in the process we may decide to delay or abort the deprecation and close this issue.

Deprecation checklist:

  • [x] Open issue (#25440)
  • [x] Perform global search for usage in public repos
  • [x] Send message to emscripten-discuss (https://groups.google.com/g/emscripten-discuss/c/oFCpwLbDLvU)
  • [x] Add "deprecation" warning to emcc (#25442)
  • [ ] Wait at least 4 releases or 2 months
  • [ ] Remove feature

sbc100 avatar Sep 30 '25 23:09 sbc100

See https://github.com/emscripten-core/emscripten/pull/25439

sbc100 avatar Sep 30 '25 23:09 sbc100

The use case of proxying to Worker itself is sound, because just enabling multithreaded programs require nonstandard HTTP server configuration.

So applications that are based on async message passing multiprocessing-style of communication could definitely utilize proxying to Worker.

It is just that the current implementation of --proxy-to-worker is monolithic, which makes it a bit dusty to keep up with the times.

juj avatar Oct 01 '25 21:10 juj

I think we should only consider keeping it around if there are active users of the feature. If there are none, I don't see any point in maintaining it and continuing to fix bugs in it.

sbc100 avatar Oct 01 '25 22:10 sbc100

I performed the following global github search: https://github.com/search?q=%2F%28%3F-i%29%5CbsPROXY_TO_WORKER%5Cb%2F+-org%3Aemscripten-core+-path%3Aemcc.+-path%3Asettings.+-path%3Asettings_reference.+-path%3Acommon.py+-path%3Ashell.js+-path%3Awasm_worker*&type=code&p=5

None of the result, as far as I can tell, were actual live usages of the setting.

sbc100 avatar Nov 06 '25 16:11 sbc100

For the --proxy-to-worker flags that where more hits, but its hard for me to tell if any of them actually live usages: https://github.com/search?q=%2F%28%3F-i%29%5Cbproxy-to-worker%5Cb%2F+-org%3Aemscripten-core+-path%3Aemcc.+-path%3Asettings.+-path%3Asettings_reference.+-path%3Acommon.py+-path%3Ashell.js+-path%3Awasm_worker*&type=code

sbc100 avatar Nov 06 '25 16:11 sbc100

As for internal usage withing google I found non at all.

sbc100 avatar Nov 06 '25 17:11 sbc100

Actually I am using it in my SimpleOMP project for creating demo pages. Well I guess I will have to set it up differently.

MuTsunTsai avatar Nov 23 '25 05:11 MuTsunTsai

Hi @MuTsunTsai, thanks for letting us know. Please let us know hard it is is for you to move to different solution. If you its not possible, and you need this feature for production usage we can consider reverting.

sbc100 avatar Nov 24 '25 16:11 sbc100

@sbc100 It's not terribly difficult, objectively speaking. I'll just have to setup my own communication with the worker and run it manually. But this feature does make it easier to generate the pages (and with less building tools needed to automate it) and I could just lock the Emscripten version for now (as I should in all cases).

MuTsunTsai avatar Nov 25 '25 01:11 MuTsunTsai