Many people have played with removing the GIL over the years in python. The issue is not that it's impossible, but rather that it's impractical and slows down the single threaded case significantly. This article did not go into details about how C extensions manage the changes, or whether they're compatible at all. It also doesn't talk about performance penalties that may be incurred by synchronizing data structures. Until we have hard data on that, this can't be called a success.
That being said, the article didn't go into any detail at all. Perhaps these questions have been answered already. Either way, this is promising step for MacRuby.
That's what I've heard about CPython's GIL, but no one has said why it slows down single threaded performance significantly. Do you happen to know?
I understand that finer-grain locking incurs more overhead, but if done well, it shouldn't be a huge performance hit. The Linux kernel at one point was protected by one, big kernel lock, too, and that was successfully relaxed.
That's been possible in python for a long time using pyprocessing (part of the stdlib since 2.5 i think). No idea about ruby but don't they have something similar?
It's too bad that MacRuby is wed to, uh Macs, as it is maturing pretty quickly. I assume that's because there is not much dissonance between the broader goals of Apple's approach to Obj-C and Ruby the language. I'd like to see a day where it isn't the bastard step-child of Ruby VM's, but I somehow doubt that will happen.
That being said, the article didn't go into any detail at all. Perhaps these questions have been answered already. Either way, this is promising step for MacRuby.