On Tue, 25 Apr 2000 [EMAIL PROTECTED] wrote:
> Let me know when you want the garbage collector. I'll re-write it in
> apache style, and add some debugging stuff. I figure there should be
> two pieces. One that analyzes the packages that are running, the
> other that actually kills off variables. This could be very usefull
> for admins that want to analyze what those huge processes really are.
what i'd really like to see is a generic symbol table walker (written in
c), where you can register callbacks foreach symbol type (SVt_*). then
once you hit an SVt_PVCV, there can be any number of registered callbacks
that fiddle with the padlist (cleaner, reporter, etc.)
> (Maybe like Apache::Memory::Cleaner, and Apache::Memory::Reporter?...
> how does that sound? We'd need some mutexes on the Registry so that
> the cleaner doesn't end up cleaning a running Registry Script <well,
> duh!>... should this extend to Handlers?)
each interpreter clone has it's own copy of the symbol table and padlists
(the syntax tree is shared).
so, in a threaded apache, the cleaner could could pop a mip->avail
interpreter and put it in the mip->busy list, in which case, nobody will
try to use it, no locking needed (other than mip->mip_lock for the avail
-> busy shift and back again).
mip == 'm'od_perl 'i'nterpreter 'p'ool, which is in the modperl-2.0 cvs
tree, not quite nailed down, but getting close.
in a 1.3-ish multi-process model, i suppose the cleaner could run as a
cleanup.
> However, if it were possible to override the "read" and "write"
> functions that would sort of "freeze" execution, and put a lock on
> this Apache registry entry (and make a unlocked copy BTW), and
> transfer it to another thread whos only job was read/write through a
> sigqueue interface... that would be REALLY cool for performance/memory
> consumption. Much less context switching overhead, and drastically
> reduced memory overhead. The problem is that who in their right mind
> has time for this sort of thing? (:->) I was thinking of implementing
> the writing of mod_proxy like this..., after considering it fully
> though, I think it would be even better to write a generalized module
> that could stream bits to clients, and use it as a plug in for any
> module that doesn't want to waste time streaming out to a 28.8k
> connection.
sounds like a piece of cake ;)
