ThreadPoolExecutor Hangs in Flask App Because uWSGI Is Running Without --enable-threads

[Bodisatva]

I’m running a Flask application that relies on reading data from a sharded database (a directory of DB files).

To speed up I/O, I use a class that maintains a small ThreadPoolExecutor (2 threads) to concurrently fetch data.
The executor is created once at app startup, shared across the app lifecycle, and properly shut down on termination.
This setup works perfectly on my two development machines (macOS and Ubuntu).
However, on the production server, any call to the fetch method hangs indefinitely — no errors, just an infinite wait.
After digging through the logs, I found what looks like the root cause:

2025-11-16 08:47:05 Python version: 3.10.5 (main, Jul 22 2022, 17:09:35) [GCC 9.4.0]
2025-11-16 08:47:05 PEP 405 virtualenv detected: /home/XXX/.virtualenvs/pi-app-XSIXLCjM
2025-11-16 08:47:05 Set PythonHome to /home/XXX/.virtualenvs/pi-app-XSIXLCjM
2025-11-16 08:47:05 *** Python threads support is disabled. You can enable it with --enable-threads ***

It appears the uWSGI instance running my Flask app was started without --enable-threads, which effectively disables Python threads.
Because of this, the ThreadPoolExecutor never schedules its work, leading to the silent hang.

The issue:
I do not have control over how the uWSGI service is started (no access to the uWSGI command or ini file), so I can’t add --enable-threads myself.

My question:
Is there any workaround or fix on the application side to make a threaded workload function under a uWSGI deployment where thread support has been disabled?

I’ve already tried rewriting the sharded DB access layer (including a DuckDB version a few weeks ago), but without understanding that threads were being blocked by the uWSGI environment. Now the behaviour finally makes sense.
Any guidance appreciated.