Paul Querna <[EMAIL PROTECTED]> wrote: > 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
