Visualising the Ruby Global VM Lock (johnleach.co.uk)

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.