On Wed, 3 May 2000 [EMAIL PROTECTED] wrote:
> So what you want is something more general, climbs through the symbol
> table and can register callbacks for various things, right? One of
right.
> which, the area I'm most interested in, is the PADLIST? Well, that's
same here!
> 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
yeah, Devel::Peek by ilya.
> 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)
the mod_perl-2.0 interpreter pool requires a -Dusethreads flavor of Perl,
which is not 5.005 threads. it wraps the Perl runtime into the
PerlInterpreter structure, which is thread-safe, assuming only one thread
is calling back into it at any given time. so if mod_perl were to spawn a
thread at startup, this thread could examine the mip->avail interpreters
without any locking.
> 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
no, we have a pool of (thread-safe) PerlInterpreters created at startup
(and at runtime as needed). at request time, inside an apache thread, we
lock the interpreter pool, pop an interpreter from the avail list, push it
into the busy list, unlock and and stash a pointer to the interpreter
inside r->pool (or c->pool for connection handlers). that interpreter is
used for any callbacks that happen in the request thread and is putback in
the avail list at the end of the request (unless PerlInterpMaxRequests is
reach or similar).
> 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?
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.
