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, at least with the sizes we're talking about for qpsmtpd.
I hope I haven't been cargo-culting then. My understanding was that Perl, being an interpreted language that precompiles it's code into a op tree that can be later changed from within the code, doesn't always work well with fork. Perhaps I'm just confusing Perl's [many] thread models (which have more serious problems in that regard). It may be that we are safe here, since we don't *want* the child copy changes to bubble up to the parent copy, but we do want the reverse to be true.
If this is true, then we should only create a /single/ Qpsmtpd::TcpServer object in the parent, and just fork off copies for each child to handle the next transaction. Most of the hooks get called in the child process, but the config changes affect the parent copy (for example) so the next fork gets them.
It also isn't necessarily a bad thing to have hooks that only run for
a certain kind of frontend type. In my production forkserver, I've
actually got pre-fork and after-child-finishes type code in to create
and delete a pidfile per process.
So that would suggest that a /pair/ of hooks be available. If we can agree to terms which describe what happens in both forksever and Apache, then that pair can be shared by the two models.
How about pre_process and post_process? I don't think prespawn and postspawn are all that bad either, since that is amorphous enough to describe both forking and what Apache does (handle'ing???). We could also just create 4 hooks that are a pair of aliases between the fork-centric names and the Apache-centric names.
cat /tmp/qpsmtpd-pid-* quickly lets me know how many connections and from which hosts.
Cool! You obviously aren't running the high_perf branch then (with its promise of many thousands of connections). :-O
After we get the hooks worked out, you'll have to post your code in the form of a plugin, then... ;-)
John
