2012/2/21 Chris McDonough <chr...@plope.com> > On Mon, 2012-02-20 at 20:54 -0500, PJ Eby wrote: > > 2012/2/20 Chris McDonough <chr...@plope.com> > > On Mon, 2012-02-20 at 17:39 -0500, PJ Eby wrote: > > > The standard way to do this would be to define an "optional > > server > > > extension" API supplied in the environ; for example, a > > > 'x-wsgiorg.register_shutdown' function. > > > > > > Unlikely, AFACIT, as shutdown may happen when no request is > > active. > > Even if this somehow happened to not be the case, asking the > > application > > to put it in the environ is not useful, as the environ can't > > really be > > relied on to retain values "up" the call stack. > > > > > > "Optional server extension APIs" are things that the server puts in > > the environ, not things the app puts there. That's why it's > > 'register_shutdown', e.g. > > environ['x-wsgiorg.register_shutdown'](shutdown_function). > > I get it now, but it's still not the right thing I don't think. Servers > shut down without issuing any requests at all. >
Yes, I also think shutting down the server is completely orthogonal to requests. Maybe another option would be to call the application with the usual callable, but an "ending request" that's a signal for the application about being shut down. When the app receives that very specific request, it would do the cleaning job. It sounds hackish but would work without changing the standard > > - C > > > > -- 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
