<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Threading is possibly even worse on Windows. Any forking on Windows is
really Perl threading as Windows doesn't have fork() as its process
model. <br>
<br>
Are you using Randy Kobes' mod_perl for ActivePerl? I have not done
that configuration for a while, but I did get it working once. Your
other option is to compile your own Apache+mod_perl -- a bit of a
challenge but certainly possible, and quite likely to resolve the
problem. <br>
<br>
The problems arise because mod_perl has to plug the whole of Perl into
Apache. This requires Apache and Perl to be compiled in ways that are
partly compatible. mod_perl has some flexibility in this, but I always
found it pretty troublesome, and in any event, the Perl threads on
Windows will be within Apache processes. FastCGI allows you to move
Perl processes outside Apache, so they are wholly independent of each
other, and no longer require any binary compatibility. <br>
<br>
The downside is that you don't memory sharing, which you get with
prefork, especially on platforms that have a proper process fork().
Unfortunately, Windows doesn't have that true fork(), so the memory
sharing is only working because you are working in a single (Windows)
process. Our Perl processes on Windows are not that big (they commonly
start at VM sizes of 50-60Mb, and only get larger when we start the
high-powered search systems we use). A decent server can easily
accommodate 40 or so of these. <br>
<br>
Personally, on Windows, I'd stick with FastCGI. We've been using it for
a year or more and it has survived some fairly large scale stress
testing. <br>
<br>
--S<br>
--<br>
<div class="moz-signature"><span style="color: rgb(102, 0, 0);">Stuart
Watt<br>
ARM Product Developer<br>
Information Balance</span></div>
<br>
<br>
Ascii King wrote:
<blockquote cite="mid:4B29430B.3010107@swattermatter.com" type="cite">Stuart
Watt wrote:
<br>
<blockquote type="cite">"Free to wrong pool" is usually an issue with
XS and threading. Digest::SHA is an XS module. Which Perl are you
using? And how is it integrated into Apache?
<br>
<br>
I've generally found FastCGI to be safer on Windows, simply because it
doesn't require the tight integration of Perl into Apache under
Windows.
<br>
<br>
--S
<br>
--
<br>
Stuart Watt
<br>
ARM Product Developer
<br>
Information Balance
<br>
</blockquote>
I have Perl v5.8.9 I suspected it was something to do with threads
only because I couldn't figure out how threading or the pre-fork stuff
was supposed to be set up on Windows. I thought I read though, that the
threading issue didn't matter on Windows.
<br>
<br>
<br>
I did have FastCGI working. I switched because the Catalyst Cookbook
recommended mod_perl. I'll try that again.
<br>
<br>
_______________________________________________
<br>
List: <a class="moz-txt-link-abbreviated" href="mailto:Catalyst@lists.scsys.co.uk">Catalyst@lists.scsys.co.uk</a>
<br>
Listinfo: <a class="moz-txt-link-freetext" href="http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst">http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst</a>
<br>
Searchable archive:
<a class="moz-txt-link-freetext" href="http://www.mail-archive.com/catalyst@lists.scsys.co.uk/">http://www.mail-archive.com/catalyst@lists.scsys.co.uk/</a>
<br>
Dev site: <a class="moz-txt-link-freetext" href="http://dev.catalyst.perl.org/">http://dev.catalyst.perl.org/</a>
<br>
<br>
--
<br>
This message was scanned by ESVA and is believed to be clean.
<br>
Click here to report this message as spam.
<a class="moz-txt-link-freetext" href="http://antispam.infobal.com/cgi-bin/learn-msg.cgi?id=0E7092806D.D7113">http://antispam.infobal.com/cgi-bin/learn-msg.cgi?id=0E7092806D.D7113</a>
<br>
<br>
</blockquote>
</body>
</html>