On Sat, 16 Aug 2008, Allison Randal wrote:
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.
the virtual interpreter scheme would certainly do the trick, as we can
initialize things the way we want (loading compilers, etc.) in the parent
and never touch it again. this also lets the HLL layer determine if and
when to discard the local changes, and mod_parrot will just provide the
appropriate hooks to do so. when in doubt, pass the buck to the HLL
layer. :)
so i guess i'll table this issue until the sandboxing is in place.
-jeff
