On Wed, Jul 30, 2008 at 3:33 PM, Tom Metro <[EMAIL PROTECTED]> wrote: > 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.
It sounded more to me like you send a regular request to the server that causes the server configuration to change. More of a remote control version than what you're describing here. Though, that said, there is little downside to using a different procedure to configure a server application than you use to access it. >> 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.) Overkill? Sure. Significant overhead? Not if the processing of a request takes any real work. If your application will ever live on more than one server, then using memcached up front is a very good idea, and using shared memory is a much worse one. > 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.) It can be implemented in multiple ways. One is that you can have it in shared memory (or a shared cache like I suggested) and the child processes regularly read that cache. Another is that you could have each child check in once per request cycle (or once every several) to see if their information is stale. If it is then they could either try to reload information, or else they could just exit and let the parent process respawn. I suspect that Apache with prefork follows the exit and respawn approach, but I don't really know. > 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. It would have to be done by the parent process, because the OS doesn't generally do that. But note that signal handling in Perl is fraught with difficulties to think about. Starting with the decision about whether you'd like to catch signals safely (no dumping core please), or in a timely fashion (don't wait until a database query ends before noticing the signal please). For this you probably want to catch it safely. However for a hard shutdown you may want to catch it in a timely fashion. Unfortunately Perl makes you choose. (But at least you can choose - it used to be that you were stuck with whichever one Perl supported, and different versions of Perl made that choice differently.) > The parent process could kill off and restart the children, though that > probably doesn't meet your criteria of not interrupting the service. That is why I suggest having the change be something the children notice somewhere in their request lifetime rather than being forcibly pushed to them. > 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. Before choosing a caching module look at http://cpan.robm.fastmail.fm/cache_perf.html and see the performance. Cheers, Ben _______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
