I for one am totally for whimsical blog titles, wouldn't you agree? In other news, after a lull of two weeks (codewise at least) I've finally started to work on mod_parrot again. The big (dis)?advantage from not working on code is that you start to think more of what you could do (and should have done), rather than what you have done.
As it turns out, I handle interpreters in a rather confused manner. My goal for the next two weeks is to fix that. First, let me describe what should be done to correctly run a script on an interpreter using mod_parrot:
- An interpreter has to be instantiated
- Proper paths have to be set up
- PIR and possibly PASM have to be loaded as intermediate code compilers
- mod_parrot specific bytecode libraries have to be loaded (to interface with apache etc)
- A loader program (cgi or psgi) has to be started
- The proper script has to be compiled
- And some invokable component of it must be invoked
- Errors should be caught and reported
- And the interpreter should be destroyed (or released at least)
As I describe it now, that is pretty much exactly what it does, however, steps 1 to 3 happen in mod_parrot_interpreter, 4 and 5 in mod_parrot_run, 6 and 7 run in common.winxed and the specific loader, 8 happens in mod_parrot_report_error and 9 happens in mod_parrot_handler. It is literally scattered all over the place.
Messy code is in reason enough for change, however this setup also prohibits me from adding the following interesting things:
- Keep a persistent (pool of) interpreter(s) in memory
- Run the user script in a separate interpreter
The two are related in an interesting way, in that the second item is required by the first. The interpreter for the user's script should be short-lived so as to clear up resources that the script might forget to release, such as open file handles. It is also required for an other reason, but that is not important right now. I'm not completely determined on how I want to do this, but a few things are clear:
- Interpreter instantiation, setup, release and destruction move to a single file (mod_parrot_interpreter.c)
- Running loaders will stay in mod_parrot_run.c
- If I had my way it would be possible to invoke an interpreter pmc with a packfileview from within winxed / pir, but that seems unlikely now
- I will need some way to determine multi-threaded running.
So, to cut this story short, a lot of work to do, but it does seem doable and beneficial too.
Until next blog, then!