[chopping down the digital forest because the light has turned on :)]
> just a seperate thread that plucks a mip->avail interpreter, puts it in
> the mip->busy list, analyzes, puts back, plucks the next mip->avail, over
> and over.
Sounds like a good plan. The first piece to put together is the
script that can register callbacks, and iterate through the perl
threads. Do we have a devel version that's got the mip->avail type
stuff together, or is this something that will be coming together in
the next few weeks? Okay so this is a module that would be loaded via
httpd.conf so that the thread can be spun off, and it can begin
analyzing. It should have some parameters so that it doesn't suck up
too much CPU time, like sleep n seconds between jumping to the next
apache embedded interpreter thread, blah, blah. Are we going to dump
this info to perlmemorylogs? (Configurable to some location, etc) Or
integrate it with some sort of online status program?
<mod_perl_status :)> Or both..., hehe, well, of course that's all
later, first piece is to get the iterator built that registers
callbacks. As an aside, I think the callback thing was a really good
idea on your part, that way you can analyze how much memory your
programs are using and whether you need to re-think your design
strategy or implement a cleaner. Any cleaner, a real aggresive one,
or a really kick back one. In any event, I just wanted to mention
that this was a really good idea of yours (the callbacks).
Thanks,
Shane.
