[mod_python] Using threading.local with Worker MPM

> 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.

> 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.

> Second is that your success may be determined by what directives you are
> using related to the Python interpreters. If you are using either of the
> directives PythonInterpPerDirective or PythonInterPerDirectory then you can
> have problems. Some of these are related to bugs in 3.1.4, some of which
> are fixed in 3.2.10.
>
> The basic problem with interpreters here is that if you are using these
> directives, or even if you are using PythonInterpreter directive
> explicitly, is that the inithandler() could be executed within the context
> of a different interpreter to your handler(). To check, out messages to the
> Apache error log in both which show the value of req.interpreter.

I'm not using any of those directives, and the req.interpreter stayed the same 
(the name of the virtual host).

> 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?

Thanks for the reply Graham!

Cheerio, Gavin.

-- 
Premolo Sàrl
Web: http://www.premolo.com/ ; Tel: +352 26687161 ; GSM: +352 091739359
42 rue du Kiem, L-1857 Luxembourg, Grand-Duché du Luxembourg