# Fastcgi and shared interpreters **URL:** \ **Category:** Ruby\ **Created:** [December 8, 2005, 6:16pm UTC](https://www.ruby-forum.com/t/fastcgi-and-shared-interpreters/49778 "2005-12-08T18:16:32Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![james\_b](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/e68b1a/32.png) [@james\_b](https://www.ruby-forum.com/u/james_b)\ **Post date:** [December 8, 2005, 6:16pm UTC](https://www.ruby-forum.com/t/fastcgi-and-shared-interpreters/49778/1 "2005-12-08T18:16:32Z")
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? Thanks, James – [http://www.ruby-doc.org](http://www.ruby-doc.org) - Ruby Help & Documentation [Ruby Code & Style](http://www.artima.com/rubycs/) - Ruby Code & Style: Writers wanted [http://www.rubystuff.com](http://www.rubystuff.com) - The Ruby Store for Ruby Stuff [http://www.jamesbritt.com](http://www.jamesbritt.com) - Playing with Better Toys [http://www.30secondrule.com](http://www.30secondrule.com) - Building Better Tools ---
**Author:** ![james\_b](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/e68b1a/32.png) [@james\_b](https://www.ruby-forum.com/u/james_b)\ **Post date:** [December 8, 2005, 7:23pm UTC](https://www.ruby-forum.com/t/fastcgi-and-shared-interpreters/49778/2 "2005-12-08T19:23:01Z")
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Dec 8, 2005, at 9:12 AM, James B. wrote: > 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) iD8DBQFDmHmaAQHALep9HFYRAhSoAKCF1n3VYnTXLWIU4A7hYLVaEnlR3gCdF3dp Fri6gTJQWRPDW41EU0H5Y4c= =Zyre -----END PGP SIGNATURE----- ---
**Author:** ![james\_b](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/e68b1a/32.png) [@james\_b](https://www.ruby-forum.com/u/james_b)\ **Post date:** [December 9, 2005, 4:41am UTC](https://www.ruby-forum.com/t/fastcgi-and-shared-interpreters/49778/3 "2005-12-09T04:41:48Z")
On Fri, 9 Dec 2005, James B. wrote: > 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. regards. -a ---
**Author:** ![james\_b](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/e68b1a/32.png) [@james\_b](https://www.ruby-forum.com/u/james_b)\ **Post date:** [December 9, 2005, 8:50am UTC](https://www.ruby-forum.com/t/fastcgi-and-shared-interpreters/49778/4 "2005-12-09T08:50:08Z")
removed\_email\_address@domain.invalid wrote: > 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. Thanks, James – [http://www.ruby-doc.org](http://www.ruby-doc.org) - Ruby Help & Documentation [Ruby Code & Style](http://www.artima.com/rubycs/) - Ruby Code & Style: Writers wanted [http://www.rubystuff.com](http://www.rubystuff.com) - The Ruby Store for Ruby Stuff [http://www.jamesbritt.com](http://www.jamesbritt.com) - Playing with Better Toys [http://www.30secondrule.com](http://www.30secondrule.com) - Building Better Tools ---
**Author:** ![james\_b](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/e68b1a/32.png) [@james\_b](https://www.ruby-forum.com/u/james_b)\ **Post date:** [December 9, 2005, 9:10am UTC](https://www.ruby-forum.com/t/fastcgi-and-shared-interpreters/49778/5 "2005-12-09T09:10:45Z")
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Dec 8, 2005, at 11:47 PM, James B. wrote: > 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) iD8DBQFDmTvsAQHALep9HFYRAlEbAJ4iOsWTtEFblJq2HT2mHZeVKBPpSgCfXODP EPmkmCVTbLyXo9RE/WaIpdw= =BFqr -----END PGP SIGNATURE----- ---
**Author:** ![james\_b](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/e68b1a/32.png) [@james\_b](https://www.ruby-forum.com/u/james_b)\ **Post date:** [December 9, 2005, 9:18am UTC](https://www.ruby-forum.com/t/fastcgi-and-shared-interpreters/49778/6 "2005-12-09T09:18:55Z")
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Dec 9, 2005, at 12:10 AM, Jeremy K. wrote: > 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) iD8DBQFDmT0bAQHALep9HFYRAt01AJ9+knr9SSFj/fbnDTGKSFPGTmeNjQCcDkb3 YMIAXrHpfFC0GNu0XRbxt44= =tXcK -----END PGP SIGNATURE----- ---
**Author:** ![james\_b](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/e68b1a/32.png) [@james\_b](https://www.ruby-forum.com/u/james_b)\ **Post date:** [December 9, 2005, 9:59am UTC](https://www.ruby-forum.com/t/fastcgi-and-shared-interpreters/49778/7 "2005-12-09T09:59:44Z")
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Dec 9, 2005, at 12:28 AM, James B. wrote: > 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) iD8DBQFDmUaCAQHALep9HFYRAu2OAJ9ITo/NlynkzSH9gkUEJrt2wQBEPwCfWMHv ZXfrMafBD6pylQejfDryFXk= =zoA2 -----END PGP SIGNATURE----- ---
**Author:** ![james\_b](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/e68b1a/32.png) [@james\_b](https://www.ruby-forum.com/u/james_b)\ **Post date:** [December 9, 2005, 10:20am UTC](https://www.ruby-forum.com/t/fastcgi-and-shared-interpreters/49778/8 "2005-12-09T10:20:07Z")
> 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. regards, George. ---
**Author:** ![james\_b](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/e68b1a/32.png) [@james\_b](https://www.ruby-forum.com/u/james_b)\ **Post date:** [December 9, 2005, 9:31am UTC](https://www.ruby-forum.com/t/fastcgi-and-shared-interpreters/49778/9 "2005-12-09T09:31:07Z")
Jeremy K. wrote: > 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. ## James [http://www.ruby-doc.org](http://www.ruby-doc.org) - Ruby Help & Documentation [Ruby Code & Style](http://www.artima.com/rubycs/) - Ruby Code & Style: Writers wanted [http://www.rubystuff.com](http://www.rubystuff.com) - The Ruby Store for Ruby Stuff [http://www.jamesbritt.com](http://www.jamesbritt.com) - Playing with Better Toys [http://www.30secondrule.com](http://www.30secondrule.com) - Building Better Tools