I’m doing more work with fascgi and scgi, and I’m looking for some
clarification. Are there configurations for either of these where
multiple application processes are sharing the same Ruby interpreter?
If my own application code is not using threads, do I need to be
concerned with race conditions or data access conflicts?
I’m doing more work with fascgi and scgi, and I’m looking for some
clarification. Are there configurations for either of these where
multiple application processes are sharing the same Ruby interpreter?
How you process requests in a FastCGI or SCGI handler is up to you.
The ‘standard’ way is to handle a single request at a time per-
process so you don’t have to worry about threading issues. However,
you could just as well dispatch the request to threads or fork children.
Best,
jeremy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (Darwin)
I’m doing more work with fascgi and scgi, and I’m looking for some
clarification. Are there configurations for either of these where multiple
application processes are sharing the same Ruby interpreter?
If my own application code is not using threads, do I need to be concerned
with race conditions or data access conflicts?
fastcgi is process based - you don’t need to worry about any concurrent
access other than between any two processes. for instance, if your
application
did something like
log = open “log”, “w”
log << 42
then you could quite possibly have two processes writing to the log file
since
apache can, depending on configuration, spawn a few processes to handle
requests. each request, however, defintely is running in one ruby
interpreter.
then you could quite possibly have two processes writing to the log file
since
apache can, depending on configuration, spawn a few processes to handle
requests. each request, however, defintely is running in one ruby
interpreter.
Right. There’s no telling what other app might be trying to access the
same external resource.
If I’m understanding this correctly, though, I need not be concerned
with contention issues any more than I would with a plain CGI app;
fastcgi and scgi are means of routing requests to persistent CGI
processes, but a given process will not be handling more than one
request at a time.
If I’m understanding this correctly, though, I need not be
concerned with contention issues any more than I would with a plain
CGI app; fastcgi and scgi are means of routing requests to
persistent CGI processes, but a given process will not be handling
more than one request at a time.
Most FastCGI implementations work this way, but it is not a rule.
You are free to write a FastCGI server which handles concurrent
requests (with threads, async IO, forked children, etc.)
But most do not; programming in the CGI style is much simpler.
The choice is yours.
jeremy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (Darwin)
You are free to write a FastCGI server which handles concurrent
requests (with threads, async IO, forked children, etc.)
In fact, FastCGI can handle concurrent requests on concurrent
connections on concurrent processes I’ve never done request
multiplexing; as far as I can tell, it’s these complexities in its
protocol that led to SCGI.
jeremy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (Darwin)
I’m writing and deploying Rails and Nitro apps and using fastcgi/
scgi at different times, and have yet to see any discussion of
threading in relation to these.
Zed’s SCGI Rails runner is threaded but serializes request processing
to emulate a single-threaded environment.
So my belief is that the fcgi and scgi code used in such cases is
not doing anything that puts conventional CGI-style code at risk.
Yes. It is safer to say that Rails and Nitro support CGI-style
programming.
But I was curious if anyone knew of something to the contrary.
You could become contrary by rewriting dispatch.fcgi
jeremy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (Darwin)
Yes. It is safer to say that Rails and Nitro support CGI-style
programming.
Nitro also supports multithreaded applications. Nitro and Og are (or
try to be) thread safe. The webrick and scgi adapters for Nitro do not
serialize the requests with a semaphore.
Most FastCGI implementations work this way, but it is not a rule.
You are free to write a FastCGI server which handles concurrent
requests (with threads, async IO, forked children, etc.)
But most do not; programming in the CGI style is much simpler.
The choice is yours.
I’m writing and deploying Rails and Nitro apps and using fastcgi/scgi at
different times, and have yet to see any discussion of threading in
relation to these. So my belief is that the fcgi and scgi code used in
such cases is not doing anything that puts conventional CGI-style code
at risk.
But I was curious if anyone knew of something to the contrary.
I’ve never done request