Forums

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.

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.

The issue: I far as I know, 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?

Any guidance appreciated.

You cannot start threads in web apps. If you need to run threads, you will need to do that outside of the web app: https://help.pythonanywhere.com/pages/AsyncInWebApps/

Thank you for clarifying.

Some providers don’t allow always-on scripts to listen on a socket. However, if PythonAnywhere does allow it, could I implement the following architecture?

• The Always-on task would run a minimalist Flask app acting as an internal REST microservice, bound only to 127.0.0.1 so it’s never exposed publicly.
• This background process would host a full ShardedDBService, along with a persistent ThreadPoolExecutor for parallel shard reads and an in-memory LRU cache to keep frequently accessed data hot.
• The microservice would expose only a few lightweight internal endpoints (e.g., /internal/data_fetch) that return JSON.
• My public Flask web app would remain thin: it would simply call these internal endpoints using requests and forward the results to the client.

This clean separation lets the Always-on task handle all heavy computation continuously while keeping the main web app fast, simple, and responsive.