

Visualising the Ruby Global VM Lock - comice
http://johnleach.co.uk/words/1245/visualising-the-ruby-global-vm-lock

======
btown
There's an endless philosophical debate between evented (Node, EventMachine)
and blocking/threaded architectures. And evented programming seems to get a
bad reputation in some circles as an "over-hyped" paradigm. But it's cases
like this where the difference becomes truly clear. A developer making a
native extension for an evented architecture is _forced_ to make every
operation nonblocking, while consistent lock release is much more of an
optional optimization for a blocking architecture. Sure, you can get equally
good performance with a blocking architecture, and slightly easier syntax, but
for many of the native extensions you might use, it's very possible that the
authors didn't think to do this type of analysis, or even know about
rb_thread_blocking_region and its ilk. So naive implementations may be wasting
threads exactly like this example. I'd much rather have nested closures where
I'm relatively guaranteed that the only inefficiencies are in CPU time rather
than blocking.

