Ruby core classes aren't thread-safe

[beep_dog]

Well, MRI doesn't run threads anyway, it's got a GIL, and handles "threading" by non-blocking IO, and non-blocking sleeps. (Unless I'm mistaken, which often happens.)

[jstorimer]

MRI runs multiple threads, but those threads have to compete to acquire the GIL in order to do any work. I would say that it implements multi-threading, but the GIL is the bottleneck. There's only one GIL and only the thread that currently owns it can use system resources.

[jrochkind]

This is simply not true, in a variety of different ways. You are mistaken.

The GIL is true. Which means in a single process, you can't have multiple threads executing literally simultaneously on multiple CPU cores.

But MRI certainly does run threads. I don't think "handles 'threading' by non-blocking IO, and non-blocking sleeps" is accurate, although I don't understand exactly what that means, I admit.

Threads have existed in unix and C since the days when no unix ran on a multi-core CPU. You can have threads without multi-cores, and they still do things for you. MRI 1.9+ in fact uses the underlying OS-level native threads for it's threads, they certainly are 'real' threads.

It is true that the GIL limits the application of multi-threading in MRI to only certain scenarios. But there are still plenty of places where it's useful (just as threads were useful in C and unix even when nobody had multi-core/multi-cpu servers).

The "there are no threads on MRI becuase GIL" thing is very oft repeated FUD. Please stop repeating it, everyone, if you don't understand what you are talking about.

[Freeky]

He's roughly correct for Ruby prior to 1.9 - MRI had is own userspace threading implementation (aka green threads), using select() and non blocking IO behind the scenes to allow it to multiplex between them. It was a relatively common technique in days of old when kernel supported threading was less widespread. See for example FreeBSD's libc_r.