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.
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.
insights are appreciated. once i know how things *should* be working, i'll open up some tickets. :)
-jeff _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
