On Wed, 10 Mar 2004, Charlie Brady wrote:
http://cr.yp.to/ucspi-tcp/tcpserver.html
The traditional qpsmtpd run script teams tcpserver and perl OK.
Here's another possible solution:
http://www.superscript.com/ucspi-tcphandle/tcpperl.html
It seems to be more or less tcpserver with an
Anyone out there willing to try some rough benchmarks on
tcpperl vs. tcpserver+pperl vs. tcpserver+speedycgi vs.
tcpserver+straight_perl?
-jc
At 12:43 PM 3/12/2004, Charlie Brady wrote:
On Wed, 10 Mar 2004, Charlie Brady wrote:
http://cr.yp.to/ucspi-tcp/tcpserver.html
The traditional
On 9 Mar 2004, at 22:32, ross mueller wrote:
Just FYI, if you try to load up qpsmtpd thats mounted on a NFS slice
with
pperl, all sorts of errors go out ;) (im sure ill get a response
saying dont
run it off an nfs slice)
anything from:
pperl: failed to read 3 bytes for an OK message:
On Wed, 10 Mar 2004, Matt Sergeant wrote:
Interesting. I've recently discovered one weird thing in pperl where
pperl tries too hard to become like the calling process, to the point
of trying to set $$ to the caller's PID. If you comment out the code
where it sets $$ everything starts
I'm curious as to whether anyone has built a forking server around qpsmtpd
(essentially doing what tcpserver does, but in perl)? I'm aware of the
select server version(*), but would prefer a forking server (say, using
Net::Daemon). That would seem to be able to provide the same speedup as
On Wed, 10 Mar 2004, Robert Spier wrote:
I'm curious as to whether anyone has built a forking server around qpsmtpd
(essentially doing what tcpserver does, but in perl)? I'm aware of the
select server version(*), but would prefer a forking server (say, using
Net::Daemon). That would seem
pperl is pre-forking.
Yes, but SelectServer isn't.
SelectServer doesn't fork at all.
It doesn't fork on every connection. The forking on every connection is
part of what causes some of the overhead.
Do you have evidence that that is the case? Fork should be inexpensive,
and it's
On Wed, 10 Mar 2004, Robert Spier wrote:
It doesn't fork on every connection. The forking on every connection is
part of what causes some of the overhead.
Do you have evidence that that is the case? Fork should be inexpensive,
and it's certainly not a problem with tcpserver.
Show of hands: how many people are using PPerl with qpsmtpd?
I recently has some arguments with my server when I updated one of the core lib/
files and couldn't get the stupid thing to use the new file. It turns out I
forgot to restart the PPerl session (`svc -t .' wasn't sufficient). It was
Apart from demonstrating my ability to forget vital features of running my
system, does anyone have an opinion about whether it is worthwhile running
qpsmtpd under PPerl???
We're running it (mostly) at perl.org, because it really hides the
startup overhead, which can have a huge effect on
On 9 Mar 2004, at 21:49, [EMAIL PROTECTED] wrote:
On Tue, 9 Mar 2004, Robert Spier wrote:
Apart from demonstrating my ability to forget vital features of
running my
system, does anyone have an opinion about whether it is worthwhile
running
qpsmtpd under PPerl???
We're running it (mostly) at
On Tue, 9 Mar 2004, Matt Sergeant wrote:
On 9 Mar 2004, at 21:49, [EMAIL PROTECTED] wrote:
I haven't been able to get PPerl to complete its tests properly -
probably minor things, but I'm not going to implement it until such
time
as all tests work.
I haven't seen reports from you
12 matches
Mail list logo
