PPerl works now. Even under CGI.
I had to remove the forking code though - so it's a bit like mod_perl under Win32 - single threaded (except with PPerl two different scripts can run at the same time - just not the same script). For some reason the forking code would cause hangs (after sorting out the hang on first request, I got hang on second request. Bah). Whereas the exact same code with the forking removed would be rock solid stable.
So, I'll get it on CPAN, and leave in pperl.h.forking, which contains the forking code. Maybe someone else can get it working.
Interestingly, I found out something intruiging about select(). If I did select with a zero timeout (poll), performance sucked. My CGI test returned 40rps vs ordinary perl's 75rps. When I set the timeout to 1ms, performance was fine (89rps). Note that the performance doesn't seem that great, but it was just the tiny printenv script that ships with Apache, so not a great example for persistent code.
I did test it on our virus scanner code though, which is 10K lines of code. Without actually scanning any viruses, startup is 0.7s with plain perl. With pperl, startup went down to 0.0s. Neat! On Monday (which will likely be today for most people reading this) I'll do some real life tests on real emails. At the moment we can parse about 14,000 emails in about 20 minutes (which isn't bad, but it is the bottleneck in our entire process). Hopefully we can bring that down to about 10 minutes or less, which will double our capacity, and/or enable the parser to get more complex :-)
I don't know if people will prefer this to SpeedyCGI or FastCGI. I don't really care all that much - it wasn't designed for CGI. It was designed for us. But I think it's cool and I like to give things away.
Must get back to XML soon. :-)
