simon holness
simon.holness at gmail.com
Fri May 11 05:22:46 EDT 2007
Hi, I'm the guy who knocked up the quick fix. Yes, I think you're quite right and the fix is also not correct. The problem appears to essentially be that a whole load of processing is happening on the 'cache' object while it isn't locked. There's always a severe danger/headache in trying to mesh two locks like this. Do you know if there's a reason that "_lock1" is used to lock out the entire of _reload_required(), rather than swapping to the use of cache.lock ? Is it to do with the processing of the cache's children? or the call to _check_module() ? The correct solution looks, to me, like all of the processing of the cache object should be guarded by its lock, and not by the _ModuleCache's _lock1. I'm not familiar enough with the code to decide if that's practicable or correct, though. Cheers Simon > Your change narrows the chance of the problem happening but does not > eliminate it completely. Also, it circumvents the whole two level > locking scheme designed to avoid slow downs in a multithreaded system. > In other words, when a module has to be imported you block all other > threads being able to load modules which don't require an actual > import. Also, I suspect the change will also cause a deadlock when a > module being imported in turn tries to use apache.import_module() as > the locks aren't reentrant by the same thread. > > More later. > > Graham
|