Threaded Request Start/Stop

[Jason Garber]

Hello Graham,

I'm working on some application code that will setup an "environment" at the start of a request, and tear it down at the end.  The environment would include authorization information, a database connection (if needed), a file server connection (if needed), and the user's session.

Since the daemon process contains several threads, steps need to be take to make sure that certain resources are only used by one thread at a time. A database connection, for example.

Knowing when a request starts is easy -- the `application` callable is called.

Knowing when a request is finished (or terminated), is where I am stuck.  

The `application(environ, start_response)` callable is called, and eventually returns an iterator.  Plain iterators are not the issue.

It's possible for the `application` callable to return a generator, which could yield a good deal of content.  Perhaps it's streaming a file from a fileserver connection, or a large number of records from a database connection.  AFAIK, the generator will continue to be called in the same thread until it's finished, and that thread will not be reused until after that point.

But... What's a clean (bullet proof) way to know when mod_wsgi has "finished" a request on a thread?

Thanks!

Jason Garber

[Graham Dumpleton]

Read:

http://code.google.com/p/modwsgi/wiki/RegisteringCleanupCode

Do note that such generator wrappers for allowing something to be
triggered when all data finally sent defeat the performance benefits
of wsgi.file_wrapper. In other words, send of file object can't be
optimised and back to normal streaming.

2009/11/3 Jason Garber <bo...@gahooa.com>:

[Jason Garber]

Read it.  Thank you. 

Just to confirm -- mod_wsgi will always call the close() method of the returned iterable?

(from what I can see in PEP 333 AND mod_wsgi.c, it appears to be the case)

Thanks!

Jason Garber

------------------------------------------------------------------------------

If the iterable returned by the application has a close() method, the server or gateway must call that method upon completion of the current request, whether the request was completed normally, or terminated early due to an error. (This is to support resource release by the application. This protocol is intended to complement PEP 325's generator support, and other common iterables with close() methods.

------------------------------------------------------------------------------

3897         if (PyObject_HasAttrString(self->sequence, "close")) {

3898             PyObject *args = NULL;

3899             PyObject *data = NULL;

3900

3901             close = PyObject_GetAttrString(self->sequence, "close");

3902

3903             args = Py_BuildValue("()");

3904             data = PyEval_CallObject(close, args);

3905

3906             Py_DECREF(args);

3907             Py_XDECREF(data);

3908             Py_DECREF(close);

3909         }

------------------------------------------------------------------------------

[Graham Dumpleton]

2009/11/3 Jason Garber <bo...@gahooa.com>:

> Read it.  Thank you.
> Just to confirm -- mod_wsgi will always call the close() method of the
> returned iterable?
> (from what I can see in PEP 333 AND mod_wsgi.c, it appears to be the case)

Yes, should always do so.

Graham