On Feb 14, 2005, at 1:54 PM, Larry Leszczynski wrote:
Depending on how bulky the regen process is, one option might be to
register a PerlCleanupHandler and let the httpd child do the regen
after
the user response is sent.
I looked into this, but I didn't like the idea of httpd getting tied
up.
On Feb 14, 2005, at 10:40 AM, Martin Moss wrote:
I have a few thoughts on this... In my experience
writing a daemon process is easy (well ish) but then
configuring your system to manage them (have they
died, have they crashed etc..) is more trouble than
its worth.
Maybe -- although thttpd has a
Sorry for the double posts -- won't happen again...
(grumble... you'd think that OSX's mail.app would be smart enough by
now so that when you reply to a message, the default account selected
is the account the message was sent to...)
- ben
On Feb 12, 2005, at 9:44 PM, ben syverson wrote:
Maybe the solution is to have 5 or 10 perl processes fire up and stay
open as daemons, processing these background regen requests?
After testing this, that looks like the way to go. The regen code now
lives as a pre-forking server, accepting
Hi Ben,
I have a few thoughts on this... In my experience
writing a daemon process is easy (well ish) but then
configuring your system to manage them (have they
died, have they crashed etc..) is more trouble than
its worth.
Is it possible to use some kind of cronjob based
system, which runs a
Hi Ben -
On Feb 12, 2005, at 9:44 PM, ben syverson wrote:
Maybe the solution is to have 5 or 10 perl
processes fire up and stay
open as daemons, processing these background regen
requests?
Depending on how bulky the regen process is, one option might be to
register a
On Feb 14, 2005, at 10:40 AM, Martin Moss wrote:
I have a few thoughts on this... In my experience
writing a daemon process is easy (well ish) but then
configuring your system to manage them (have they
died, have they crashed etc..) is more trouble than
its worth.
Maybe -- although thttpd has a
