[mod_python] Using threading.local with Worker MPM

Graham Dumpleton grahamd at dscpl.com.au
Thu Aug 17 01:52:31 EDT 2006

Gavin Panella wrote ..
> > I presumed you added calls to apache.log_error() to confirm your
> > inithandler() was actually being called?
> I added logs to the init handler and the main handler, and I also logged
> every 
> __(get|set|del)(attr|item)__ and clear of instances of my shared space
> class. 
> At every point I recorded the id()s of relevant objects, the current thread
> id, and the current contents of the space.
> News just in: I've tried using the non-C version of threading.local, to
> be 
> found in _threading_local.py, and it works fine. There is a performance
> hit 
> apparently, but I'm not bashing it hard enough to notice any difference.
> This 
> might point to some late night under-the-covers C shenanigans.

Not that it will matter, but where are you storing the thread local variable?
Is that in a module that can be reloaded automatically by mod_python?

Maybe someone else who has Python with native thread local storage can
try it. I only have 2.3.5 which I believe can't do it.

> > Anyway, first off is that there are bugs in mod_python 3.1.4 related
> to the
> > creation of the Python interpreters and thread locking. I am not sure
> how
> > this would affect use of thread local storage, perhaps not depending
> on
> > where the data is held, but would definitely suggest you upgrade to 3.2.10.
> There are no 3.2 ebuilds in Gentoo yet, so I'll hang on for the moment.
> I 
> could upgrade by hand, but I have to be able to repeat this easily on other
> machines and I'm short on time. Sorry about that. I'll have a look at the
> change log and try not to whine too much about things that are fixed :-)
> > This doesn't eliminate all module reloading problems, but gets rid of
> a few
> > nasty ones.
> As a side note, the setting of PythonAutoReload did not make any difference.

Was fixed in 3.2.8.

> > You need to know the correct set of directives to use in order to get
> the
> > authhandler() and authzhandler() to trigger. This includes use of the
> > Require directive but possible also AuthType and AuthName. Problem is
> that
> > in 3.1.4 even if you can get it to trigger you still may have problems
> if
> > you have multiple stacked auth[z]?handler() functions as mod_python doesn't
> > interpreter return status codes properly. This is fixed in 3.3.
> >
> > Suggest you post to the mailing list what directives you were using to
> try
> > and attempt to trigger the authzhandler().
> I saw a thread about this where you gave some advice, but I couldn't get
> things to work. And I can't remember the set of directives now. Is it Apache
> that needs to be induced into the auth/authz phases, or is it mod_python?

It is Apache that has to be prodded into running the auth/authz handler


More information about the Mod_python mailing list