Matthew Byng-Maddick wrote:
>
[useful description snipped]
> Obviously, if your modperl is URL dependent, then you can't determine what
> URL they are going to ask for at the time you have to call accept. The only
> alternative way of doing what you're asking for is to use file descriptor
> passing, which is still about *the* topmost unportable bit of UNIX. :-(
> It is also quite complicated to get right.
Aah! Ok.
> It isn't, because otherwise there'd be even more context-switching, (which is
> slow). The clean solution, in this case, would be to have the one apache that
> actually accepts, does a bit of work on the URL, and then delegates to
> children (probably by passing the fd), but then you still have to do rather
> too much work on the URL before you can do anything about it.
Is this how Apache 2 works, then?
> It isn't as unclean as you might think, though.
>
> Hope this helps
No, but it explains things a bit better. ^_^
Thanks!
I suppose another way to do it is to go the way of the "application server",
where a light apache daemon then talks to a separate, dedicated, server for the
application. I do use FastCGI for some applications, which runs an app as a
separate process (and can support multiple processes, even on remote machines),
but I like mod_perl's ability to layer multiple content handlers.
I suppose there isn't a mod_perl implementation of FastCGI, is there? (To allow
mixing FastCGI application processing with other mod_perl content handlers) (Or
layer multiple FastCGIs?).
I haven't seen much support for FastCGI as I'd expect. Is there something
similar that's better that everyone's using and not telling me about? ^_^
--
. Trevor Phillips - http://jurai.murdoch.edu.au/ .
: CWIS Systems Administrator - [EMAIL PROTECTED] :
| IT Services - Murdoch University |
>------------------- Member of the #SAS# & #CFC# --------------------<
| On nights such as this, evil deeds are done. And good deeds, of /
| course. But mostly evil, on the whole. /
\ -- (Terry Pratchett, Wyrd Sisters) /
