3 ms·

> Python/Flask has no central "application" concept, They do, it's a WSGI application. Flask has been multithreaded for many years. Python also has multi-proce

• alanfranz 7y ago
  WSGI is purely an interface between a webserver and python. What has WSGI to do with state? The application server model makes it so there's a running application, with a state, and which exposes an HTTP endpoint. > Flask has been multithreaded for many years So? You run a blocking thread to performing a long-running task in Flask? With Python? Try, then report what you find. Flask/Django are mostly designed to work with a stateless approach. Nothing wrong with that, but it's got drawbacks. > multi-process queues that don't need an extra process. More processes usually imply more complexity. And still, since you don't have a central application with a state, you NEED an extra piece to manage the result from the queue.
  • icebraining 7y ago
    > So? You run a blocking thread to performing a long-running task in Flask? With Python? Try, then report what you find. I did it for years. It works just fine. The GIL is essentially like running an app on a single core, which works just fine for many use cases. CPU cores are quite powerful. > More processes usually imply more complexity. Right, but I'm only saying you can have more processes without requiring Redis. > And still, since you don't have a central application with a state, you NEED an extra piece to manage the result from the queue. A regular thread can do that.