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 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 gre
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. Th
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. Th
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 gre
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 P
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 scr
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 connec
