Problems with gencache on Windows NT
gtalvola at nameconnector.com
Thu May 10 14:39:59 EDT 2001
At 01:29 PM 5/10/01 -0400, Geoff Talvola wrote:
>At 12:26 PM 5/10/01 -0400, Geoff Talvola wrote:
>>Actually, I just today discovered a gotcha with using EnsureDispatch. It
>>appears to be non-thread-safe. If multiple threads are simultaneously
>>trying to EnsureDispatch, I get problems.
>>My solution for now is to just use EnsureModule at import time, but that
>>obviously defeats the purpose of EnsureDispatch.
>>So it would be nice if EnsureDispatch could be made thread-safe. Another
>>solution would be to allow EnsureModule to be passed in a nice string
>>like "Scripting.Dictionary" instead of the GUID, to make it nicer to use.
>I experimented a bit with this, and it turns out that an easy way to make
>both EnsureDispatch and EnsureModule thread-safe is to simply wrap the
>entire contents of EnsureModule with a lock. Mark, any chance this fix
>could be made in gencache.py? I made this change in my copy of
>gencache.py and it fixed my problem:
>_ensureModuleLock = threading.Lock()
> # do the EnsureModule thing here...
Well, I spoke too soon. It turns out that I need to wrap both EnsureModule
AND EnsureDispatch with locks in order to solve my problem. I still get
On a related note, I've noticed that EnsureDispatch seems to _always_ call
EnsureModule, which makes it quite a bit slower than Dispatch (although
it's still plenty fast). I wonder if this is a bug in EnsureDispatch -- it
looks like it was intended to only call EnsureModule the first time
through. Probably only Mark can answer that. I'm using win32all 136 with
Python 1.5.2 in case it matters.
OK, I'll stop replying to myself now...
- Geoff Talvola
gtalvola at NameConnector.com
More information about the Python-list