On Tue, Feb 21, 2012 at 10:24 AM, Graham Dumpleton < graham.dumple...@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
_______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
