[mod_python] RE: Bug in mod_python.c causing multiple/redundantinterpreter creation.

Graham Dumpleton grahamd at dscpl.com.au
Sun Oct 17 22:17:15 EDT 2004

On Sunday, October 17, 2004, at 03:54  PM, Graham Dumpleton wrote:

> On 17/10/2004, at 9:32 AM, Graham Dumpleton wrote:
>> I knew there was an issue with apache.py as well, with there being no 
>> locking,
>> but didn't mention it in my email with the fix as I wanted to check 
>> that that
>> was the source of the other problem I was seeing and make sure I came 
>> up with
>> a proper fix.
> Turns out I had made the fix to the import_module() method as the 
> first thing I
> did, looks like I forgot. This is actually the way I uncovered that 
> there was still
> a further problem and thus the bug with creation of multiple 
> interpreters. I spent
> a good few hours tracking the problem done and then coming up with a 
> fix. Drove me
> nuts for a while as I knew exactly what I had to do to fix it but the 
> result would
> just hang. Finally realised the locking had to be done outside of the 
> GIL locking
> and not inside. Putting it inside later resulted in deadlock.
> Anyway, the fix to apache.py I am running with at the moment is:
> try:
>   from threading import Lock
> except:
>   class Lock:
>     def acquire(self): pass
>     def release(self): pass
> _lock = Lock()

Whoops. That should be RLock and not Lock. Lock is not reentrant so if 
a module which
was being imported called back into import_module(), it would deadlock 
on itself. Thus
should use RLock instead. Ie.,

   from threading import RLock
   class RLock:
     def acquire(self): pass
     def release(self): pass

_lock = RLock()

The two level locking scheme is still going to be better, as an import 
that takes
a long time to execute is going to block out new requests for that 
time. The
import_module() method really needs to be rewritten completely to 
address this
properly. :-(

Graham Dumpleton (grahamd at dscpl.com.au)

More information about the Mod_python mailing list