I'm implementing a long-running thread within a Flask application. In debug mode, with the reloader activated, the long-running thread is not killed upon reload.
Instead, because the code that creates and starts the thread is run after reloading, each cycle creates an additional thread.
How can I prevent this, other than disabling the reloader?
Will the same happen when running under mod_wsgi, with its auto-reload feature?
Update: the long-running thread was actually killed by Werkzeug upon reloading. There is an extra copy, which is due to Werkzeug's reloader taking an extra thread which runs the initialization code.
The mod_wsgi reloading is described in:
http://code.google.com/p/modwsgi/wiki/ReloadingSourceCode
In the case of a long running request, by default if it doesn't complete within 5 seconds the process will be forcibly killed anyway. This is to avoid problem of process locking up because a request will not finish.
Related
I have read the documentation of uWSGI mules, and some info from other sources. But I'm confused about the differences between mules and python threads. Can anyone explain to me, what can mules do that threads cannot and why do mules even exist?
uWSGI mule can be thought of as a separate worker process, which is not accessible via sockets (eg. direct web requests). It executes an instance of your application and can be used for offloading tasks using mulefunc Python decorator for example. Also, as mentioned in the documentation, mule can be configured to execute custom logic.
On the other hand, a thread runs in its parent's (uWSGI worker) address space. So if the worker dies or is reloaded, the thread behaves the same way. It can handle requests and also can execute specified tasks (functions) via thread decorator.
Python threads do no span on multiple CPUs, roughly said can't use all the CPU power, this is a Python GIL limitation What is the global interpreter lock (GIL) in CPython?
This is one of the reasons for using web servers, their duty is to spawn a process worker or use idle one for each task received (http request).
A mule function on the same principal, but is particular in a sense that it is intended to run tasks outside of an http request context. the idea behind, is that you could reserve some mules, each will be running in a separate process (span on multiple CPUs) as regular workers do, but they don't serve any http request, only tasks to be setup as mentioned in the uwsgi documentation.
Worth to mention that mules are also monitored by the master process of the web server, such they are respawned when killed or dead.
I use flask as http server, for Multi-threaded support, I set threaded=True
The Call Stack shows every thread is running and not cancel when function finished.
And the memory has been growing.
I use tornado framework solved it.
When developing a bottle webapp with python 3.5, I regularly get a zombie process. I get this when using the auto-restart development mode.
The windows console still updates with the access logs, and the errors, but the program isn't running in foreground anymore, so I can't access it to use Ctrl+C.
The only way to kill this is to open the task manager and end the process manually.
If I don't kill it, it will still be listening on the port, and have precedence on a newly started process.
I haven't found a rule for when this happens, nor have I found a way to reproduce.
How can I avoid this multi-spawned zombie process?
In uWSGi document, there is a sentence said, If you start uWSGI without threads, the Python GIL will not be enabled, so threads generated by your application will never run
I wonder how uWSGi disable python GIL?
It replaces the functions for getting and releasing GIL (they handle switching threads) with a dummy functions doing nothing. See related source code:
Initializing thread switching to dummy by default:
https://github.com/unbit/uwsgi/blob/edb93f6c174a61858be88c9c2eb2c34bf87ae07d/plugins/python/python_plugin.c#L309-L311
Dummy GIL functions:
https://github.com/unbit/uwsgi/blob/abac960e62700117cb96af3cd22e27e04242e096/plugins/python/gil.c
I would like to run some code in a uWSGI app, but on a long-lived process, not inside workers. That's because the process blocks on a socket recv() call, and only one thread of execution should do this.
I am hoping to avoiding creating my own daemon by somehow starting a long-lived process on uWSGI startup that does not get spawned in each worker.
Does uWSGI support anything like this?
uWSGI Mules are like workers but without network access:
http://uwsgi-docs.readthedocs.org/en/latest/Mules.html