[#29911] [Bug #3231] Digest Does Not Build — Charlie Savage <redmine@...>

Bug #3231: Digest Does Not Build

19 messages 2010/05/01

[#29920] [Feature #3232] Loops (while/until) should return last statement value if any, like if/unless — Benoit Daloze <redmine@...>

Feature #3232: Loops (while/until) should return last statement value if any, like if/unless

9 messages 2010/05/01

[#29997] years in Time.utc — Xavier Noria <fxn@...>

Does anyone have a precise statement about the years supported by

13 messages 2010/05/04

[#30010] [Bug #3248] extension 'tk' is finding tclConfig.sh and tkConfig.sh incorrectly — Luis Lavena <redmine@...>

Bug #3248: extension 'tk' is finding tclConfig.sh and tkConfig.sh incorrectly

9 messages 2010/05/05

[#30226] [Bug #3288] Segmentation fault - activesupport-3.0.0.beta3/lib/active_support/callbacks.rb:88 — Szymon Jeż <redmine@...>

Bug #3288: Segmentation fault - activesupport-3.0.0.beta3/lib/active_support/callbacks.rb:88

10 messages 2010/05/13

[#30358] tk doesn't startup well in doze — Roger Pack <rogerdpack2@...>

Currently with 1.9.x and tk 8.5,the following occurs

12 messages 2010/05/22

[ruby-core:30017] Re: [Bug #3212] ConditionVariable may become inconsistent for interrupted threads

From: Yusuke ENDOH <mame@...>
Date: 2010-05-05 10:16:53 UTC
List: ruby-core #30017
Hi,

2010/5/5 Sylvain Joyeux <redmine@ruby-lang.org>:
> Ruby allows condition variables to be interrupted by exceptions, and it should therefore *work when it is used*. It is a grave bug, as it will lead to weird, hard-to-debug situations for people that use Ruby normal features (exception handling and multi-threading).

Umm, Okay.  I'll accept your fix unless there is objection.

But, you should *not* use Thread#raise if you are serious about multi-
thread programming.  It has a potential race condition:

  1) an exception is raised by another thread
  2) rescue/ensure clause is going to be executed
  3) another exception is raised by another thread
  4) rescue/ensure clause are not executed

An exception raised by another thread cannot be handled safely.


> I'm really getting tired of having to deal with multi-threading issues with Ruby.

I understand your irrits, but in fact, Ruby's thread is very immature
in a sense of both design and implementation.  This is unfortunate, but
the fact.


> If MT is so low-priority in the MRI world, maybe you guys should remove it completely from the interpreter.

I think it is good idea, with no apparent sense of irony, though
it is of course impossible.


> you would have to rewrite the whole of the MRI multi-threading implementation.

I think so, honestly.
We need contribution from those who are familiar with multi-thread
programing.

-- 
Yusuke Endoh <mame@tsg.ne.jp>

In This Thread