[Web-SIG] A 'shutdown' function in WSGI
ziade.tarek at gmail.com
Tue Feb 21 11:41:38 CET 2012
On Tue, Feb 21, 2012 at 10:24 AM, Graham Dumpleton <
graham.dumpleton at gmail.com> wrote:
> > But I don't think you can guarantee that everything is still up in
> memory by
> > the time atexit gets called,
> > so you can't really call cleanup code there.
> The only thing which is done prior to atexit callbacks being called is
> waiting on threads which weren't marked as daemonised.
which can lead to completely lock the shutdown if a lib or the program has
a thread with a loop that waits for a condition.
which it is not the case with signals, since you get a chance to properly
stop everything beforehand.
> what do you mean by bypassing its destruction ?
> Non catchable signal from within process or from a distinct monitoring
> One of this things I pointed out is being missed.
> That is, a WSGI adapter may be running on top of another layer of
> abstraction, such as FASTCGI for example, where the lower layer isn't
> going to have any callback mechanism of its own to even notify the
> WSGI layer to trigger registered cleanup callbacks.
> This is why the only mechanism one can universally rely on is the
> Python interpreters own atexit mechanism.
I see.. but what I don't understand is the following: when the whole stack
is shut down, the python process is being killed by *someone*.
And that someone, as far as I understand, is also able to send requests to
the WSGI application.
So what makes it impossible to send a shutdown signal prior to killing the
Sorry if I miss the obvious, I am probably over-simplifying things here :d
Tarek Ziadé | http://ziade.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Web-SIG