Ben Tilly wrote:
But you'll probably want a plain text file to be written out somewhere in the background to preserve data across server restarts.
I think the OP is referring to a typical scenario where you update a configuration file, and then send a signal to the process to provoke a re-read of the configuration file.
If you want to guarantee that your application can never scale, then you could use shared memory. If you want your application to be able to run on multiple machines, then I'd suggest that you use memcached.
Isn't memcached overkill for a handful of config variables that rarely get reloaded? (Assuming I understand the scenario correctly.)
Ranga Nathan <[EMAIL PROTECTED]> wrote:
I realize that one of the children would get the message indicating the changes. If it updates the data structure in memory that would do it only for THAT client, right? In other words, what is the best way for all the children to share variables?
This concept is certainly common enough in UNIX. Take Apache, for example. But I've never had the need to look into exactly how it is implemented. (The multi-threaded/multi-process services I've written in Perl haven't had the need to reload config files while running.)
If a signal directed at the parent process gets propagated to the children (either by the OS or by the parent process), then with a bit of redundant inefficiency, you could have a signal handler in each child reload the configuration and update their local copies of the variables.
The parent process could kill off and restart the children, though that probably doesn't meet your criteria of not interrupting the service.
If you were using Perl's threads, there's a built-in mechanism for declaring shared variables. Otherwise, I'd investigate the various shared memory and IPC modules on CPAN. There are a few IPC modules in the core distribution.
-Tom -- Tom Metro Venture Logic, Newton, MA, USA "Enterprise solutions through open source." Professional Profile: http://tmetro.venturelogic.com/ _______________________________________________ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
