Questions about Embedding Parrot / mod_parrot
Paul Querna
I just started hacking on Parrot Yesterday, so if some of these
questions have easy answers, please point me in the right direction.(I
have read most of the PDDS / fair ammount of the other PODs).
I have started work on building a new Apache 2.0 Module to run Parrot.
The old Module for Apache 1.3 does not look maintained. I was able to
get the Parrot VM to init itself quite easily. The ICU data directory
was a bit of a pain, and I had to manualy call
'string_set_data_directory(...)' myself.
Here are my questions:
1) Parrot_exit() - This is used in many places after an error occurs.
This function calls any exit callbacks previously entered, and then
calls exit(). This is horrible from an embedding perspective. In
particular, it should be avoided in the Apache model, where many threads
in the same process are handling other requests. I believe it should be
a runtime configuration setting to not exit() on error, but use some
other error handling. The use of exit() is a signifigant problem for
any embedding attempt. Just because parrot is having problems, that
does not mean you want to call exit().
2) Thread Safety - How thread safe is a Parrot Interpreter? I have seen
some past notes that a single Interpreter should not be used by multiple
threads at the same time. My current plan is to create a Pool of
Interpeters to be used in Apache. Each active request will be using a
seperate Parrot Interpreter. This is how mod_python operates.
3) Getting Vars to a script - In an Apache Handler, the request_rec
struct carries all the information about the HTTP Request. I want to
get a Pointer to this struct down to a PMC that then can be used by Any
Script. How do I do this?
Perhaps I am thinking too much in terms of Ferite
( http://www.ferite.org ), but steps I would take are after starting the
engine are:
- Create a Variable
- Register that Variable in a Namespace
- Run the Script
- Access the Variable in its Namespace from the Script.
The end user script doesn't have to do anything extra, they just access
the variable in its namespace.
I am not sure how this would work in Parrot. I did not see any examples
in the Test code of a Pointer being set in a PMC, and then that PMC
being accessed later in a seperate script (but the same
interpreter....)
The old Apache 1.3 Module handled this in an Evil(tm) Way. It set the
request_rec to a static global, and accessed it in a completely
non-threadsafe method. This is not a viable option in the Apache 2
Model, where many common high performance MPMs are heavily
multi-threaded.
I guess the real question out of this is, What is the best way to get a
pointer to a struct from my C with Parrot embedded, to be accessable to
a script ran by my Interpreter?
4) Any other gotchas or recommended reading about Parrot?
Thanks for the Help,
-Paul Querna
Leopold Toetsch
> I have started work on building a new Apache 2.0 Module to run Parrot.
> 1) Parrot_exit() - This is used in many places after an error occurs.
> This function calls any exit callbacks previously entered, and then
> calls exit(). This is horrible from an embedding perspective.
Yep. The main problem is that by far not all internal code paths are
using exceptions so that you could interfer the exit handling. This
needs of course being fixed somewhen.
> ... I believe it should be
> a runtime configuration setting to not exit() on error, but use some
> other error handling.
The problem here is to bring the interpreter into a state so that it's
reusable to service a new request. I don't know yet, what's necessary to
run the same byte code or a different piece of code. How much cleanup is
necesary and so on.
I think the simplest thing is to interfer Parrot_exit (by installing an
exit handler) then trigger creating a new interpreter for your pool of
interpreters and let the old one die.
> 2) Thread Safety - How thread safe is a Parrot Interpreter? I have seen
> some past notes that a single Interpreter should not be used by multiple
> threads at the same time. My current plan is to create a Pool of
> Interpeters to be used in Apache. Each active request will be using a
> seperate Parrot Interpreter. This is how mod_python operates.
Yep, that's the way to go. You have to use separate interpreters.
> 3) Getting Vars to a script - In an Apache Handler, the request_rec
> struct carries all the information about the HTTP Request. I want to
> get a Pointer to this struct down to a PMC that then can be used by Any
> Script. How do I do this?
$ perldoc -F docs/pmc/struct.pod should have the necessary explanation,
how to access items inside a struct (pointer).
> -Paul Querna
leo
Chromatic
> Yep. The main problem is that by far not all internal code paths are
> using exceptions so that you could interfer the exit handling. This
> needs of course being fixed somewhen.
Is this as simple and tedious as replacing all Parrot_exit() calls with
internal_exception() calls of the appropriate name?
-- c
Leopold Toetsch
No. C<internal_exception> does call C<Parrot_exit>. The former should be
converted to C<real_exception> with an appropriate exception object (of
some exception class scheme) to carry on the relevant information to
(possibly installed) user handlers. All of this is AFAIK.
> -- c
leo