... it's green threaded.
That means, the threading is simulated by the Ruby VM and they are not "true OS threads".
That means, if a thread in your Ruby program makes a call that the VM can't suspend, all threads running in that VM will block. In effect, your Ruby VM will "hang" until the rogue thread returns.
A few links about how threads in Ruby work:
Basically, the recommended way to achieve concurrency, if each concurrent thread/process is doing even moderately complex I/O tasks, is to fork a new process. (The much-touted "shared nothing" architecture)
PS: And in case you're wondering, ActiveRecord *is* thread-safe. It's just that most apps don't use it because of the preferred way of achieving concurrency in Ruby (forking processes).
It's worth noting that this is mainly an issue when calling out to C extensions. All "pure Ruby" code can be pre-empted by the Ruby interpreter, but C code called via extensions can not.
ReplyDeleteSince you mention Active Record, it's worth remembering that this in particular applies to the MySQL C extension, for example, so if you use Active Record against MySQL (and probably other database servers too), there are a number of situations (different types of network problems etc.) where your Ruby process is guaranteed to lock, in which case the only way to prevent the process from hanging indefinitely is to use Alarm() to trigger a signal on timeout.
Ruby 1.9 should fix this, though.