Hello all the discussion has become a little bit technical for me...
What I understand is that I've been lucky to make this work so far and that sooner or later I will end up with some problems.
Is there some not-too-complicated way to workaround the problems in the perl scripts or at least prevent the most severe problems to happen?
NOTE: Actually what I'm currently doing is a authentication handler derived from Apache::AuthCookie. My handler is connecting to a database through Win32::OLE to authenticate users. Active connections are kept in a cache until users logout.
From what I understand of Jan's answer: should I keep an active connection per thread-id?
Jan Dubois wrote:
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
--
Thierry Valentin earth decision sciences SA /(formerly known as T-Surf)/ 22, allée de la Foret de la Reine 54500 Vandoeuvre-lès-Nancy, France Email: [EMAIL PROTECTED] Phone: +33 (0)3-83-67-66-29 Fax: +33 (0)3-83-67-66-34 Please visit our website at: www.earthdecision.com <http://www.earthdecision.com/>
-- 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
