perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Foo JH <jhfoo...@extracktor.com>
Subject Re: Theory and practice of mod_perl win32
Date Mon, 07 Jan 2008 03:29:10 GMT
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 testers@httpd and dev@httpd 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


Mime
View raw message