3 ms·

I have to completely disagree. I think GIL is useful in ruby and is a mitzvah, not a sin. Reason: Well bla bla bla unicorn does light-weight forks. But the rea

I have to completely disagree. I think GIL is useful in ruby and is a mitzvah, not a sin. Reason: Well bla bla bla unicorn does light-weight forks. But the real fun is in "synchronized" keyword of java. You see, in java multithreading is hard, but it is a heluvalot easier than in many other languages, ruby included. If anything, we should design "Truby" which is a new languages for multi-threaded ruby. Truby will need syntax for dealing with asynchronous operations. Truby can then remove the GIL and life will be good. The problem is that you take ruby as it is and remove GIL, sure you can get away with things, rewrite libs, etc, but in the end you won't have a really good language for async programming anyways. So yes, just use processes. Once we have a good multithreaded op model without a GIL then we can just use threads. Until then... edit: jruby can get away without a GIL because it relies on libraries implemented in java, which have very little issue writing async code.

cbs 15y ago
>But the real fun is in "synchronized" keyword of java. Can >we should design "Truby" which is a new languages for multi-threaded ruby But thats just syntactic sugar for managing a lock. I don't follow ruby exceptionally closely, is the syntax of the language frozen forever? Can similar sugar not be added?
- superjared 15y ago
  When I did multi-threaded Ruby stuff (shudders) I wrote a simple lock block using either an object or a symbol as the lock identifier. The resulting code looked like: lock(some_obj) do // synchronized code here end Using a mechanism like that you can add synchronization to Ruby without any new syntax.
  - dlikhten 15y ago
    yes, true, but the real fun is in making design decisions with respect to how threads work etc to ensure true concurrency and easy concurrency. Good concurrency frameworks, etc. TBH we can do that now with the GIL by giving ruby code to a c-library that handles multi-threaded calls. But end-of-the-day lets change the game, no act catch-up to java.
- mitchty 15y ago
  Yes it can, but its not needed directly. Maybe for Ruby 2.0 this could get shoehorned in. JRuby and (sharpish) Rubinius can already do GILless ruby execution. But that doesn't mean everything "just works", it only exposes the problems both languages have when two concurrent contexts try to update the same object, like adding hash elements at the same time. In JRuby it throws an exception, at least allowing you to retry, Rubinius is copying that behavior as well. But technically, there is no standard for what happens. My knowledge of non CPython interpereters isn't enough to talk about their GIL or lack thereof implementations.

cbs 15y ago

>But the real fun is in "synchronized" keyword of java. Can >we should design "Truby" which is a new languages for multi-threaded ruby But thats just syntactic sugar for managing a lock. I don't follow ruby exceptionally closely, is the syntax of the language frozen forever? Can similar sugar not be added?

superjared 15y ago
When I did multi-threaded Ruby stuff (shudders) I wrote a simple lock block using either an object or a symbol as the lock identifier. The resulting code looked like: lock(some_obj) do // synchronized code here end Using a mechanism like that you can add synchronization to Ruby without any new syntax.
- dlikhten 15y ago
  yes, true, but the real fun is in making design decisions with respect to how threads work etc to ensure true concurrency and easy concurrency. Good concurrency frameworks, etc. TBH we can do that now with the GIL by giving ruby code to a c-library that handles multi-threaded calls. But end-of-the-day lets change the game, no act catch-up to java.
mitchty 15y ago
Yes it can, but its not needed directly. Maybe for Ruby 2.0 this could get shoehorned in. JRuby and (sharpish) Rubinius can already do GILless ruby execution. But that doesn't mean everything "just works", it only exposes the problems both languages have when two concurrent contexts try to update the same object, like adding hash elements at the same time. In JRuby it throws an exception, at least allowing you to retry, Rubinius is copying that behavior as well. But technically, there is no standard for what happens. My knowledge of non CPython interpereters isn't enough to talk about their GIL or lack thereof implementations.