On Thu, Nov 13, 2003 at 02:32:57PM -0500, Brad Lhotsky wrote: > 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.
(The Proc:: namespace is not related to /proc beyond the fact they both relate to processes.) > 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::* ? Yes, Parallel:: is better than Proc:: for this. But there's no need to have multiple levels below that. Parallel::ForkControl is fine. Tim.
