There are similar modules, but their interface is different. I've only found Parallel::ForkManager to be close, implementation wise, to do what my module does. I aimed to remove all the fork controlling code/logic away from the main program. The way I've implemented the module, the code in your perl program is ALWAYS in the parent process UNLESS its in the code ref that you pass to the module at creation. It made more sense to me to divide things up.
Also, I didn't feel like Proc::* was a good namespace, as right now, there's no reliance on /proc. As an interim solution the program is just using the uptime command to get load information. I want to remove this, because I feel its awkward, and replace it with /proc related goodness. This will also afford me the ability to deal with children on a process level, monitoring not only system, but process health. I like the idea of a a ForkControl::* name space and separate implementations based on what's available. Perhaps a ForkControl::Unix which implements controls on a very generic basis, utilizing command output to judge system health (things like uptime, vmstat, etc, etc) a ForkControl::Proc which can use information out of the /proc filesystem, and so on and so forth? I could even abstract out the Implementation and make a ForkControl that detects the environments and uses the ForkControl::* of best fit. Warning when a control method is unavailable under a certain circumstances. Maybe is should live under Parallel::Fork::Control::* ? or Fork::Control::* ? thoughts/comments appreciated On Thu, Nov 13, 2003 at 05:39:50PM +0000, Tim Bunce wrote: > On Thu, Nov 13, 2003 at 11:56:02AM -0500, Brad Lhotsky wrote: > > but the idea is to extend the module using the /proc > > filesystem (hence the name space) > > > > 2) Is 'Linux::ForkControl' a decent name for this module? > > Other operating systems have /proc interfaces. (Perhaps not identical > to Linux but some are probably supportable). > > Why not use the Proc:: namespace? Proc::ForkControl > > But aren't ther similar modules already? Why add a new module > instead of extending an exisiting one? > > Tim. > -- Brad Lhotsky <[EMAIL PROTECTED]>
