On Fri, Jul 05, 2002 at 01:20:21PM +0100, Roger Burton West wrote: > Alternatives which have occurred to me: > > (1) fork, subprocess "require"s the relevant monitor (packaged in a > module). Still has Perl-parsing delays. > > (2) load up _all_ monitor modules from the start. Much bigger memory > footprint, especially since I want to keep the fork ...
I would do the latter. Having one app sitting around chewing up a chunk of memory isn't much of a problem. And when it forks, most of that memory will be shared with the child process. I suppose it depends to a certain extent on how much memory the machine has and exactly how your monitoring process works - if, for example, your monitor spends most of the time sleeping, just occasionally prodding things on the network, then I imagine that fair sized chunks of it might end up being swapped out most of the time if memory is tight. -- David Cantrell | [EMAIL PROTECTED] | http://www.cantrell.org.uk/david Pressure was growing last night for the global "war on terror" to be broadened to take in a wide range of other 'rogue emotions' including horror, shock and a general feeling of bewilderment about the state of the world. -- The Brains Trust
