[Catalyst] Why use external FastCGI apps?

[Yuval Kogman]

On Thu, Feb 07, 2008 at 13:05:48 -0500, Matt Pitts wrote:
> Thanks for explanation, this makes a lot of sense to me. 
> 
> Does anyone know if Apache's mpm_worker is compatible with mod_fastcgi and external fastcgi? Is there any real benefit of threads in this scenario?

threaded mpm for apache is orthogonal to this, it only applies to
mod_perl itself.

Within your external or managed fastcgi you can use threads or forks
or whatever, there is no relation between them anymore, except
through the named socket (the user running the fastcgi must be able
to write to the dir making the socket, and the user running the
webserver must be able to read the socket).

In general threads for perl are... not that hot. The only plausible
reason I can think of for using threads out of choice is... uh.
can't think of any. =P

Since inter thread data sharing in perl is kinda clunky (you need to
recursively share an entire data structure, you can't just pass
references through some queue) they offer no real advantage over
traditional IPC with separate processes (they do consume more memory
as a general rule though).

-- 
  Yuval Kogman <nothingmuch at woobling.org>
http://nothingmuch.woobling.org  0xEBD27418

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.scsys.co.uk/pipermail/catalyst/attachments/20080207/dec1b35d/attachment.pgp