On 9 January 2015 at 10:40, bulk88 <bul...@hotmail.com> wrote: > sisyph...@optusnet.com.au wrote: >> If different runtimes are used (as might happen with your other-way-about >> configuration) then you can run into problems - eg when a handle that has >> been created by one runtime gets passed to the other runtime (whereupon the >> "other" runtime says "wtf is this ?" and promptly crashes). >> From memory, Win32::SharedFileOpen was unusable if the compiler that >> built it used a different runtime to that used by perl. > > > That would be a coding mistake that is easy to fix if you have all the > source code available. Use perl exported win32_*() functions, not c std lib > (MS CRT) functions. That guarantees you are using the same CRT as perl even > if you/your compiler doesnt know the name of that CRT or what it is. Also > Perl [annoyingly] hooks most of CRT, and all of stdio with CPP macros, from > the code inside XSUB.h. I have never personally seen any negative effects > from multiple CRTs in 1 perl process/XS module being a different CRT from > core's CRT. Of course for L2 caching reasons, multiple CRTs are bad, but > many apps (try firefox) will have multiple CRTs inside for various reasons.
The problem with Win32::SharedFileOpen was fixed except for the outstanding problem with perl interp structs detailed in perl #121448.
