[Web-SIG] A 'shutdown' function in WSGI

[Tarek Ziadé]

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
process.
> 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
process ?

Sorry if I miss the obvious, I am probably over-simplifying things here :d

Cheers
Tarek
-- 
Tarek Ziadé | http://ziade.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/web-sig/attachments/20120221/60c35894/attachment.html>