At 12:02 Uhr +0200 09.05.2002, J�rg Walter wrote: >On Wednesday, 08. May 2002 22:50, Matt Sergeant wrote: > >> One proposal I have for AxKit 2.0 would be to not use mod_perl at all, but >> to customly embed perl. The advantage would be we wouldn't need mod_perl >> any more, and we could customise AxKit so that it's much easier to >> separate from Apache module design (e.g. using CGI). The disadvantage >> being that mod_perl is highly developed, so we might miss out on that. But > > we don't use much of mod_perl, so I'm not too worried about it.
What comes to my mind: exception handling. Uncatched perl exceptions thrown in XSP files, custom providers etc. should have a common last catcher (the current error stylesheet mechanism). Without perl at the top, who would do it then?(*) (BTW I'll send a small patch shortly that improves this function of AxKit.pm) >But that will give other problems. Imagine two perl interpreters linked at the >same time - unless mod_perl is compiled as DSO, it will probably crash. I know from some own experience that standard perl doesn't accept multiple interpreters in the same process, regardless whether a shared libperl is used. You have to compile perl with an option to enable multiple interpreters (something in the same direction as multithreading) and then explicitely create a new interpreter and switch contexts as described in perlembed. But I don't know whether you would need a separate interpreter anyway, why not load the custom stuff into the same? (apart from my above concern) Christian. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
