Re: acgi - a fastcgi alternative?

On Tue, Mar 25, 2003 at 08:00:49AM +0900, ahoward wrote:
> > FastCGI is working very well for me, and I'll certainly persist with it -
> > there's a lot of development already behind it, and the ability to run perl
> > CGIs under the same API is extremely useful.
> 
> i agree with you.  however, my take is the benefits/complexity ratio is simply
> not there for fastcgi and that this is why more people have not adopted it.  i
> have been using it myself and really like it...

I'm not sure why it hasn't taken off so much. Many CGI application writers
use PHP, and PHP support is noticeably missing from www.fastcgi.com, so they
are forced to use mod_php. Perlers will likely use mod_perl if their
webserver has it compiled in already, which is often the case (more than
mod_fastcgi anyway)

From my point of view, FastCGI is the simpler alternative. One Apache module
lets me run persistent C programs (e.g. sqwebmail), Ruby programs and Perl
programs. Furthermore I get better visibility, since each application runs
as a separate process, and therefore I can see it in 'top', attach a ktrace
to it, etc.

Also, an application can be restarted automatically if its source file has
changed (although not the libraries it depends on):

  FastCgiConfig -autoUpdate

> > I am just in the process of updating the ruby-fcgi module (programs now run
> > either from the command-line, as normal CGI, or as FastCGI with no changes!)
> > I'll post it tomorrow when I've finished working out why FreeBSD appears to
> > be mangling signals...
> 
> i spent quite a few hours mucking with that too.  signals are evil IMHO and
> should be steered clear of if simplicity and robustness are really desired.
> i'm not saying it can't be done - just that it's one of those slipperly slopes
> like threads and continuations.

I don't think it's that bad. The confusion arose because Ruby's "traps" sit
on top of OS "signals" and aren't just the same thing. Ruby installs its own
handlers for the majority of signals, _and_ it marks them with SA_RESTART so
that interrupted system calls are automatically restarted. When a signal
occurs, it takes action based on its internal trap table. So when you change
handlers using 'trap' it doesn't actually change the signal handler
installed in the OS.

When you understand it, it's a nice abstraction though. You can protect
critical code with

     trap('SIGUSR1') { flag = true }
     ... critical code
     trap('SIGUSR1','DEFAULT')
     break if flag

then a USR1 which happens outside this block will be handled immediately,
raising an exception, but if it happens inside this block it will be
deferred until the end of the critical section.

Regards,

Brian.