> 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.)
So what you want is something more general, climbs through the symbol
table and can register callbacks for various things, right? One of
which, the area I'm most interested in, is the PADLIST? Well, that's
certainly something that could be put together. What I had worked on
and have right now is something that is adapted out of Peek::Devel,
(something like that..., I can't remember, by Ilya?) originally it was
designed to trace through and report on the various variables in the
PAD, but not too specific on data on that. So what we're talking
about now is hooking up a module that you could register callbacks for
PADs into secondary modules, reporters, cleaners, that sort of thing.
Sounds cool to me :-). Now... how are we going to give this thing
execution time?, is it something that is spun out as a thread
everyonce in a while, or everpresent going through all the
interpreters data? (Obviously this would only be possible in a fully
threaded version of perl), or will it actually be part of the threads
that are running perl scripts? (So that we won't have to deal with
locking issues)
> > (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.
Okay..., so in 2.x we're actually having threads that are dedicated to
perl? I.e. seperate and apart from direct serving actions? Or did I
misunderstand what you're saying here. So the cleaner would be an
internally triggered event, and run in the context of the running
thread. It would say: "Hey I'm busy" and not get anymore requests,
then it would start analyzing it's own data structures. Or are you
speaking of a seperate thread running in the own variable space as the
other threads which tells that thread to stop serving requests, and
analyzes it's cloned version of the registry?
>
> 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 ;)
>
hehe, cake, as in the 6 months it takes to make phefernoose cookies
(that is a total mis-spelling). It was just a crazy idea, but it
would take a lot more people than one to implement. I'm thinking of
laying the foundation that others could build off of later, like
puting the mod_async thing together with void* pointers so it could
hold a pointer to anything and pass it back to who ever called it
later.
Anyhow..., that's later, I'm working on sending first... it's kind of
more universally applicable anyway.., the reading is a "specific
case".
Thanks,
Shane.
