Jeff Horwitz wrote:
i ran into a major stumbling block during my latest mod_parrot hackathon.
mod_parrot supports global, per-server, and per-section interpreter
pools. new interpreters are created using Parrot_new, passing in the
parent interpreter if one has already been created. all of this works
great when the only language in use is PIR, but once you throw rakudo
into the picture, things blow up pretty spectacularly.
rakudo uses dynops, and when both a parent and child interpreter load
rakudo, the child actually tries to load the dynops again, even though
they're already loaded and shared globally. this can actually
"succeed", but it corrupts the parent interpreter in the process. there
are checks to avoid this situation, but they are only triggered when
creating threads. and even if they were triggered, they'd throw an
exception and i'd be stuck without rakudo.
In the short-term, the best solution is to trigger the same checks as
threads in the child interpreter (assuming those checks are able to
safely detect that the dynops are already loaded and globally shared),
but instead of throwing an exception, simply succeed without reloading.
It's essentially like Perl's 'use' (where a module is loaded once, no
matter how many times various parts of the code 'use' it), or more
primitively like ifdef-ing C header files so they're only included once.
the child interpreter is NOT a clone, so i MUST reload rakudo in order
to use it.
i have several thoughts on this. first, it seems to me that
dynop_register needs to be smarter in simple multi-interpreter
environments, doing the right thing or failing with an exception if it
can't. second, we need a robust way to clone interpreters from an
embedded environment. that way i can load all the HLLs up front and
clone as necessary. that may be a post-1.0 discussion though.
Ultimately, we should be able to completely clone an interpreter,
including loaded dynops and dynpmcs, and loaded libraries. You shouldn't
have to reload rakudo on every child interpreter.
The short-term solution doesn't conflict with the long-solution, and
really should happen anyway.
Allison
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
