On 2005-04-25 21:47:21 +0200, Peter J. Holzer wrote:
On 2005-04-25 11:02:41 -0400, John Peacock wrote:
Peter J. Holzer wrote:
For small values of sort of, yes. It must be called after register (of
course), so it would actually be called from Qpsmtpd::TcpServer::run.
It would probably make
Robert Spier wrote:
There's no real difference between C code and perl code when it comes
to fork.
Cool. I'm going to continue to remain largely ignorant of threads then, since
they scare me...
There are some things to keep in mind though. Anything that needs
things that are different in the
There are some things to keep in mind though. Anything that needs
things that are different in the child will need to be handled
properly. If the TcpServer object stores PID, that's not good.
It doesn't; only the parent tracks the PID (in forkserver). It seems
to be sufficient to just
Robert Spier wrote:
Well, it really depends. If you're creating it once in the parent and
then using the copies in the child, you'll actually save time. With
modern operating systems, a fork is actually pretty cheap. Most use
copy-on-write, so it doesn't matter too much how big the process is,
Thanks, John, your mail was very helpful.
On 2005-04-25 11:02:41 -0400, John Peacock wrote:
Peter J. Holzer wrote:
For small values of sort of, yes. It must be called after register (of
course), so it would actually be called from Qpsmtpd::TcpServer::run.
It would probably make sense to move
On 2005-04-22 15:24:57 -0500, David Nicol wrote:
STARTUP suggests program startup to me, not connection startup. We
already have some pretty long hook names like unrecognized_command or
reset_transaction, so mabe we should just call it startup_connection
or accept_connection. Or
STARTUP suggests program startup to me, not connection startup. We
already have some pretty long hook names like unrecognized_command or
reset_transaction, so mabe we should just call it startup_connection
or accept_connection. Or global_connect/shared_connect to stress
that it is called in a
On 4/20/05, Peter J. Holzer [EMAIL PROTECTED] wrote:
So I think a prefork hook which is called just before the fork would be
best. Arguments should probably be $client (the socket) and $hisaddr.
Comments?
if qpsmtpd plugin compatibility is to be maintained across process management
David Nicol wrote:
if qpsmtpd plugin compatibility is to be maintained across process management
architectures (I imagine a process pool model, like apache's) we'd want to
define this hook in terms of how it fits into the flow. Calling it
PREFORK would
work, yes, but maybe PREGREET might be
