On Mon, 29 Nov 2004, Stas Bekman wrote: > If you just call perl_clone it runs in the new perl context, but > inside the same thread. At least on Unix. Under ithreads.pm it > probably starts a new thread first (but I'm not sure). Under > modperl 2, there is no 1:1 relationship between interpreters and > apache threads > > so that means that it's out of question that Win32::OLE can be used at > all, right? I suppose Thierry was just lucky to get the thing working > by loading at request time, and most likely under a bit of stress > testing it'll show the same problems.
Yes, it sounds like COM and mod_perl threads won't mix. Even if Win32::OLE was made thread-safe (I still have that on my todo list), it would probably not work with mod_perl 2.0 because COM objects have apartment affinity. You can't just create a COM object in one thread and then use it from another. It will have to be explicitly marshaled in case the different threads belong to different threading apartments. This means COM will create a proxy object in the calling thread and uses something like in-process RPC to execute the call in the "home-thread" of the real object. I guess this can be worked around too, by storing the "owning" thread id in each Win32::OLE object and then explicitly requesting it to be marshaled if it is being used from a different thread. But that will only work if both threads will properly crank the Windows message loop, in case one of the threads belongs to a single threaded apartment. It becomes a big can of worms... It looks like "thread-safety" has a whole range of meanings in the ithreads world. :( Cheers, -Jan -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
