Not sure this is the best place to post, but:
I have a Perl daemon using Net::Daemon (technically it uses
RPC::PlServer, which inherits from Net::Daemon).
When the daemon starts up, it reads a bunch of system configuration
information into internal hashes etc., then invokes Bind() to wait for
requests. I'm using the fork model and that works fine and I want to
keep using it (allows concurrent client support, doesn't mess with
threads).
Here's the thing: sometimes the configuration files on the system
change. I'd like to enhance my daemon so that it could detect these
changes itself and reload the cached information.
Today what happens is that the child process that's forked detects the
changes and re-reads the cache... but then the whole idea of the cache
is not very useful because the child process exits, and the next one
has to do the same thing. This is OK for a little bit, but it sucks
over the long term.
What I need to do is get the master daemon process to reread IT'S
caches, so that future children will have up-to-date caches and won't
have to go through that work.
I'm not sure the best way to do it, though. Looking at the man page for
Net::Daemon it seems I only have one option: set the loop-timeout
parameter, then create a Loop() method that re-reads the caches. The
man page recommends also setting the loop-child parameter, but of course
that would defeat the entire purpose so I wouldn't do that.
Is this the only way? The best way? Other suggestions? Things I
should be careful about?
It would be nicer if there were some way for the child to signal the
parent that its caches are dirty, so they can be updated immediately
instead of once every N minutes or whatever with Loop(), but that's not
critical.
Cheers!
--
-------------------------------------------------------------------------------
Paul D. Smith < XXXX@XXXXX.COM > HASMAT--HA Software Mthds & Tools
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
These are my opinions--Nortel takes no responsibility for them.