Can we deprecate `--proxy-to-worker` / `-sPROXY_TO_WORKER`?
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
See https://github.com/emscripten-core/emscripten/pull/25439
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.
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.
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.
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
As for internal usage withing google I found non at all.
Actually I am using it in my SimpleOMP project for creating demo pages. Well I guess I will have to set it up differently.
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 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).