[mod_python] Some observations after writing my own modpython

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Graham Dumpleton wrote:
> Wow, when I suggested that it was more 'tongue in cheek', if you
> understand the expression. 

Of course.  But the code was fresh in my mind so what the heck :-)

> The complaints one keep seeing about fastcgi/scgi is that it is a pain
> to setup both in the fact that you need to install separate backend
> packages and also in the configuration. 

Can't that be fixed by better documentation/installers?

> You also see various
> complaints about it those process will just die or will hang around
> and not die.

I assume that is bugs in wsgiref or one of the other servers.

> Overall, the intent is to make it as secure, simple and uncomplicated
> as possible for web hosting companies so they can see it as a viable
> option for hosting Python web applications.

I'd strongly recommend putting that paragraph at the top of the modwsgi
home page.  A problem with a lot of open source projects is that they
don't say what they are really good at.

> Anyway, again, it is all about providing a system which is going to be
> safe to use in shared web hosting environments where users can't
> create havoc.

def handler(...):
   while True:
      pass

> There are no APR functions in Apache 1.3. It doesn't have some
> equivalents as ap_ functions but not as many.

I guess you'd have to use the Python equivalent functions then.

> Also, the apr_ functions
> mean you are using the Apache memory pools. I didn't want to use the
> memory pools as then the cumulative memory used is held until the end
> of the request, whereas using malloc/free means only hold memory for
> just the period I need to.

I can't imagine requests live that long to matter.  Also if you are
talking premature optimizations, I believe it is far more effective to
have the one free called that gets rid of the whole pool rather than
individual frees.  The main thing that seemed wierd in the code is that
it was doing these precise allocations whereas I'd expect Python or apr
to do allocations larger than you requested so that when you add more
chunks of data the space is likely already there.

>> You may find it worthwhile using PyObject_CallFunction instead of
>> BuildValue and CallObject.  You have one less thing to track refcounts
>> for and one less line of code.
> 
> Probably just did it that way as that is what the basic Python
> documentation examples use and so have always done that.

Yes, it would be nice if the docs and examples showed other functions
you can use, especially ones that result in less code and one less
variable to keep track of references on.

>> For the various objects that have a request_rec*, I don't see how they
>> deal with outliving the request_req.
> 
> They don't and since I keep pushing this idea that mod_wsgi is meant
> to be as secure and robust as possible to satisfy web hosting
> companies, maybe I should.

reqs=[]

def handler(req):
   reqs.append(req)
   [r.uri for r in reqs]

That code will cause a core dump :-)

> Strictly speaking though, a WSGI application should not be retaining
> references to the WSGI environment, the start_response function or
> anything else provided as part of the request. If it does, then it is
> incorrect.

There is incorrect, and there is crashing the entire process :-)

> Maybe I misunderstand what you are talking about, or to what level you
> are applying it. What I thought you meant is that if one access an
> attribute of request_rec, such as content type, that you create a
> Python string object and return it, but that you also remember that
> Python string instance so the next time content type is access in same
> request, that Python string instance which is being held is return
> instead of having to create a new one.

OOR is not referring to individual attributes and "small" types such as
string and integer but rather objects such as what wraps the
request_rec, server, apr_tables etc.

> Anyway, thanks greatly for reviewing my code and commenting on it.
> Just about everyone grabs the code and uses it, rather than digging
> into what it does and giving any feedback and how to make it better.

You are welcome.  It was interesting for me too.

Roger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGZYgbmOOfHg372QQRAoaSAJ4tU16GndmvMOomUYzPw5rt4N+WhgCdEOB9
lFcRVenn25VgX5y8P+PywSE=
=GvGG
-----END PGP SIGNATURE-----