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. > > tcpserver is designed to fork and exec lightweight C programs.
I don't see "lightweight C" here: http://cr.yp.to/ucspi-tcp/tcpserver.html The "traditional" qpsmtpd run script teams tcpserver and perl OK. > forking larger programs (i.e. perl) can be an issue. Much less of an issue with modern CoW fork. > And there is definitely overhead to forking. Sure, but it's not necessarily a dominating issue in the design decision. The fork per se is not the problem, it's the subsequent exec and perl startup which is the real expense. > > > Net::Daemon can do preforking too. > > It can, but is latency critical enough for it to be an issue? > > Yes. Care to explain? Do you have any figures to back up the assertion? I'm not trying to disagree with you, I just want to be sure that it's worth any effort to optimise. (Although, with Net::Daemon, it's probably a tiny change of code to have one or t'other). --- Charlie
