Theory and practice of mod_perl win32
Anyone following the dialog on [EMAIL PROTECTED] and [EMAIL PROTECTED] is already aware of problems users are hitting with httpd 2.2.7 and modperl. Here's my current theory in search of a sanity check. There are two general classes of 'major issues' that we are going to encounter with msvc interop between httpd, perl and modperl. * malloc'ator flaws; memory allocated in one components heap and later freed in another * stdio/posix io handles. These don't map between one and another. To solve the first issue, there is only one solution. Because perl and modperl are both managing perl memory allocate/free, those must be compiled against the same msvc lib. That means using perl's compile hinting. In practice, this may be the difference between a user who says "yup, works for me" and those who fail utterly. Likewise they should use an openssl etc which are compiled against perl's choice, or that blows up for certain openssl-oriented xs's which have the same tight integration. To solve the second issue, I think we can hack it. What if modperl verified, and reinitialized if necessary, the stdio handles associated with "its msvcrt" during the register_hooks phase and again during the open_logs hook (run as 'very last'). This should ensure the stdio handles are legit even if httpd started under one msvcr, while perl and modperl are running under another. Just a thought, I have a bunch on my plate but I wanted to float a possible solution. Bill
Re: Theory and practice of mod_perl win32
Thinking from the perspective of the developer who tries very hard to avoid dealing with C/C++, can the ApacheLounge patches and compilation do the trick? Caveat: have not read the dialog on the mailing list described. William A. Rowe, Jr. wrote: Anyone following the dialog on [EMAIL PROTECTED] and [EMAIL PROTECTED] is already aware of problems users are hitting with httpd 2.2.7 and modperl. Here's my current theory in search of a sanity check. There are two general classes of 'major issues' that we are going to encounter with msvc interop between httpd, perl and modperl. * malloc'ator flaws; memory allocated in one components heap and later freed in another * stdio/posix io handles. These don't map between one and another. To solve the first issue, there is only one solution. Because perl and modperl are both managing perl memory allocate/free, those must be compiled against the same msvc lib. That means using perl's compile hinting. In practice, this may be the difference between a user who says "yup, works for me" and those who fail utterly. Likewise they should use an openssl etc which are compiled against perl's choice, or that blows up for certain openssl-oriented xs's which have the same tight integration. To solve the second issue, I think we can hack it. What if modperl verified, and reinitialized if necessary, the stdio handles associated with "its msvcrt" during the register_hooks phase and again during the open_logs hook (run as 'very last'). This should ensure the stdio handles are legit even if httpd started under one msvcr, while perl and modperl are running under another. Just a thought, I have a bunch on my plate but I wanted to float a possible solution. Bill
Re: Theory and practice of mod_perl win32
Foo JH wrote: Thinking from the perspective of the developer who tries very hard to avoid dealing with C/C++, can the ApacheLounge patches and compilation do the trick? Your question is irrelevant. Reread the post. Caveat: have not read the dialog on the mailing list described. Might be a good idea first. It's essential underlying issues, not a matter for how someone builds httpd, unless httpd is build against MSVCRT.DLL (which the ASF is doing, but most VS 2005 users aren't.) My point was (if you reread the post) that if modperl is built in the same way as *perl*, and some minor code changes are made with respect to how perl creates a MSVCR## perl-friendly environment, some of these unavoidable issues might be avoided ;-) If httpd | modperl is the demarcation, then the various ways that modperl directly manipulates perl internals (and how xs extentions interact with perl internals) aren't an issue, and for the most part there should not these sorts of issues between modperl and httpd if we do get that demarcation right. Bill
