After all these years, I have made the one XS module I have somewhat thread-safe. That is, when I let DTS (an SQL Server component) spawn of a bunch of parallel ActiveX scripts, they all succeed. There may still be glitches though.
Before I go on, I should say that this module encapsulates a DLL which is only available on Win32, so this is the only platform of interest. One thing I know though, is that the whole thing is leaking memory. What I do in my bootstrap code is to allocate a buffer for thread-global data which I store with TlsSetValue. But I can find any corresponding to BOOT for when the script exists. There is DESTROY, but that is for an object, and a thread may create more than one object. (And it may for some reason create no object at all.) Of course I could add a procedure to the interface of the XS, which a script which is involved with threads would have to call. I see on the Perlxs page, that there are new macros in 5.8 which are intended for multi-threaded applications. Is there some automagic deallocation that comes with them? Or would they leak in the same way as my TlsSetValue solution would do? The context where I believe multi-threading is of most interest is in the context of a web-server which keeps the DLL for the XS loaded, and the script is activated through ActivePerls PerlScript. (The original problem was in this case my module failed when you boot-strapped it a second time.) -- Erland Sommarskog, Stockholm, [EMAIL PROTECTED]
