Hacker News Reader

Comment by cbs | Hacker News Reader

>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?

View on HN

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.

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.

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.

Reply on news.ycombinator.com