Jeff Horwitz wrote:
i'd like to have an option in mod_parrot to clear all user-generated
data (globals, namespaces, subs, etc.) from an interpreter, leaving any
bytecode that has been loaded (e.g. compilers). the point here is to
eliminate problems caused by data persistence on hosted web servers,
which is one of several reasons why many hosting companies don't offer
mod_perl. the persistence might even cause problems with pipp/PHP, as
it's not expected for data to persist, so this is something mod_parrot
needs to support.
i'm sure we'd have to provide some significant hints to whatever routine
is doing the dirty work, but before i even start to look at this, is it
even possible with our current architecture? can we get close?
It would be tricky at the moment. It'll be much easier once security
sandboxing is in place. You'll be able to run mod_parrot code in a
virtual interpreter that only has access to make local modifications,
though it can read from the parent interpreter. (Think of it as a COW
scheme, or lexical interpreters.) So, you can discard the cheap local
overlay to get rid of local changes, and still have the full interpreter
running in the background with all its loaded modules.
Helpful, but not absolutely necessary, would be a list of what should
persist and what shouldn't. PHP might provide a good starting point for
the list. It's not just a matter of "keep loaded modules but discard
variables" because loaded bytecode may create package or class variables
too.
Allison
