On Jan 31, 2006, at 5:11 AM, List R. wrote:
Zed’s SCGI Runner (SRR) is committed to using Ruby threads, not
processes or even native OS threads.
Yes, this is true but there’s not much other choice. Sad fact is
that even Ruby’s own IO.select has problem with Ruby’s own
threads. Apart from using a special build of Ruby that has native
threads there isn’t much you can do.
Incidentally, you should read http://www.kegel.com/c10k.html to
understand why processes and threads don’t give you performance.
This means it will never have the stability and robustness large
scale, critical apps need.
Never is a pretty strong word, but I will say you should look at my
other project in the works called Mongrel (http://rubyforge.org/
projects/mongrel/) for clues to the next release of SCGI.
A misbehaving thread can bring the whole thing down. It can lock
keep the whole system locked. A long syscall can paralyze everything.
I’ve tried the SRR (can’t beat it’s simplicity or coolness!), but
give it up due to this problem.
This is true as well. If you write code that makes a thread
misbehave then you are screwed. It is easy to avoid the problem by
simply making sure that you clean up all your created resources when
your controller action finishes–which is what you should be doing
anyway. That being said it’s a pretty big change for some people to
make since it requires understanding how their resources should be
managed. The next release may try to help people out with this, but
I’m also afraid this will make SRR more complex.
BTW, I’d love a small sample snippet of code which demonstrates this
problem. I’ve had maybe 3 people complain about this yet none of
them could give me a piece of sample code which replicated the
problem. It’s really driving me insane.
Zed A. Shaw