6 ms·
Ruby 2.0 still has the GIL so if you want to run a threaded web server you'll still need to be using rubinius or jruby.
by atambo 14y ago
Ruby 2.0 still has the GIL so if you want to run a threaded web server you'll still need to be using rubinius or jruby.
- jrochkind1 14y agoONLY if it's important to you that one process be able to run multiple threads on multiple CPU cores concurrently. Even without this, there are MANY use cases where multi-threaded concurrent request dispatch makes a LOT of sense. For instance, the recent controversy about heroku routing, right? With MRI or another interpreter with the GIL, you'd want to run one app process per CPU core -- but having each of those processes also do multi-threaded request handling can still even out latency (that is, avoid those awful ~95th+ percentile latencies in the heroku routing debacle), and increase overall throughput. Especially if your app, like most but not all web apps, is more I/O bound than CPU bound (waiting on DB, disk, or external APIs).
- nefasti 14y agoAny reason ruby still has the GIL and not moved to a thread implementation?
- steveklabnik 14y agoMatz likes the fact that it Just Works and you can't accidentally have weirdness based on how your code runs. There aren't any plans to remove it at this time.
- 33degrees 14y agoI can imagine a whole bunch of gems suddenly breaking if this changes...
- steveklabnik 14y agoThat's true, but I don't buy that argument: look at how fast everyone has updated their gems to be Ruby 2.0 compatible. The Ruby world likes running on the edge; if MRI forced us to consider thread safety, we'd learn about the issue much quicker as a community. Since we'd be forced to. ;)
- 33degrees 14y agoOh I don't doubt that the community would move quite quickly to support it, but it certainly wouldn't be without some bumps along the way!
- FooBarWidget 14y agoThe GIL makes a lot of things in the Ruby interpreter much easier to implement.