On Fri, Oct 24, 2008 at 8:47 AM, weepy <[EMAIL PROTECTED]> wrote: > > Aparently it's not quite that straight forward. > > http://m.onkey.org/2008/10/23/thread-safety-for-your-rails > > I'm assuming that much of this is relevant to merb.
Yes. MRI < 1.9 threads are green threads, running inside of a single process. They are blocked, generally speaking, by any chunk of non-ruby code that doesn't allow for thread scheduling. This includes almost all Ruby extensions, as well as parts of Ruby that keep their execution locked up inside non-context-switching pieces of C, like the regexp engine. So, if you have a regexp that is slow, your other threads will be blocked while it runs. In MRI Ruby < 1.9 there are 2 situations where threadsafe status is helpful. 1) Your code has _external_ latencies which can be captured via _nonblocking_ IO. 2) You want to keep your system somewhat responsive to new requests while handling one or more slow, _nonblocking_ requests. One process _can_ handle quite a bit of traffic. I have built dozens of production sites which run on a single process. However, when using MRI, be best way to scale is to use a multiprocess model, regardless of whether each process is itself threadsafe or not. Kirk Haines --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "merb" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/merb?hl=en -~----------~----~----~----~------~----~------~--~---
