Current Situation
Users frequently run into unexpected webserver "freezing" when using sync effects due to Python's single-threaded nature. This is seemingly caused by the ASGI websocket consumer being blocked from receiving/sending data during hook operations. This behavior doesn't seem to match up with equivalent JavaScript server side frameworks.
Proposed Actions
By default we should run all sync effects in a ThreadPoolExecutor(max_workers=1). This effectively runs all sync effects in a background thread. Additionally, by running all effects in the same worker thread (max_workers=1) this implementation is semi-threadsafe (as long as the user didn't start an operation outside of his use_effect call. For operations that must run on the main thread, we need a @use_effect(threading: bool = ...) parameter to switch back to legacy behavior.
We could also consider a reactpy.config.USE_EFFECT_WORKERS=... setting to allow users to modify the value of max_workers.
Current Situation
Users frequently run into unexpected webserver "freezing" when using sync effects due to Python's single-threaded nature. This is seemingly caused by the ASGI websocket consumer being blocked from receiving/sending data during hook operations. This behavior doesn't seem to match up with equivalent JavaScript server side frameworks.
Proposed Actions
By default we should run all sync effects in a
ThreadPoolExecutor(max_workers=1). This effectively runs all sync effects in a background thread. Additionally, by running all effects in the same worker thread (max_workers=1) this implementation is semi-threadsafe (as long as the user didn't start an operation outside of hisuse_effectcall. For operations that must run on the main thread, we need a@use_effect(threading: bool = ...)parameter to switch back to legacy behavior.We could also consider a
reactpy.config.USE_EFFECT_WORKERS=...setting to allow users to modify the value ofmax_workers.