Doug & modperlers...
> however, padlists are not shared. as i mentioned, i'd like to look at
> using your "garbage collector" for 2.0. if it could run in it's own
> thread and examine the padlists of idle interpreters, it could be big win.
> i wouldn't want it to release all allocations in the padlist by default.
> maybe be configurable to only release things of a certain size. what i
> would personally like to see is one that just reports anything that's
> larger than X size, so i can fix the Perl code not copy large chunks of
> data, and/or figure out how to make large chunks of data shared between
> interpreters. i kinda started this with the B::Size hooks in
> Apache::Status, but you have to dig around the symbol table to find how
> big things are, there's no overall reporting mechanism.
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.
Are they all code?, are they stack variables? A reporting module
would be really cool, and it would answer a lot of questions that I
have. So you're right..., I think that's the first piece that should
be implemented. I just need to re-write it for multiple levels of
recursion (Present version only scans the first level). Basically
re-hack it to exclude actual cleaning, and just reporting, and maybe
as a secondary module a cleaner. Something like use
Apache::Cleaner..., in a fully threaded apache only one thread would
be needed. In a process enviro... arg!... I don't want to think about
that right now... I know the answer but I just hate to say it.
(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?)
>
> > One of my concerns is that maybe the apache module API is simply too
> > complex to pull something like this off. I don't know, but it seems
> > like it should be able to handle something like this.
>
> if you need a model where the Perl engine is in a different process
> than Apache, that should be implemented with FastCGI or something else.
> the overhead of passing the request_rec (and everything it points to)
> between processes for all of the various phases (so mod_perl could
> still everything it can today) would be a nightmare.
I really don't need such a model at this time. However I was thinking
about it..., and aside from the point that Stas brought up, I think
this would be an interesting avenue to look through... that's
essentially how mato_perl works. The crazy idea that I forwarded to
Stas was something like this: The problem with having one thread is
network reads. This is actually a really big issue all in all.
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. Anyhow... this is my present obsession, and I'm hoping to
have a beta patch to mod_proxy in about a month. But if I were to
re-implement it as a generic apache module, and give it some state
context, and the ability to read and write, it could be very very
usefull for nearly anything for apache. (Obviously sigqueue's aren't
implemented on every platform, so either poll(), or select would take
it's place in these scenarios... still more efficient than having a
"heavy" mod perl enabled server sending data to 28.8k client)
Anyhow... thanks Doug,
Shane.
(Man, you've got a good memory... that was over two months ago I
brought up the GC)
