Problems with gencache on Windows NT

[Geoff Talvola]

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:
>
>import threading
>_ensureModuleLock = threading.Lock()
>def EnsureModule(...):
>     _ensureModuleLock.acquire()
>     try:
>         # do the EnsureModule thing here...
>     finally:
>         _ensureModuleLock.release()

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

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