|
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.,
try:
from threading import RLock
except:
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)
|