[#24105] [Bug #1711] Marshal Failing to Round-Trip Certain Recurisve Data Structures — Run Paint Run Run <redmine@...>

Bug #1711: Marshal Failing to Round-Trip Certain Recurisve Data Structures

9 messages 2009/07/01

[#24116] [Bug #1715] Numeric#arg for NaN is Inconsistent Across Versions — Run Paint Run Run <redmine@...>

Bug #1715: Numeric#arg for NaN is Inconsistent Across Versions

10 messages 2009/07/02

[#24240] [Bug #1755] IO#reopen Doesn't Fully Associate with Given Stream on 1.9; Ignores pos on 1.8 — Run Paint Run Run <redmine@...>

Bug #1755: IO#reopen Doesn't Fully Associate with Given Stream on 1.9; Ignores pos on 1.8

8 messages 2009/07/09

[#24321] [Bug #1773] Gem path doesn't honor user gem? — Lin Jen-Shin <redmine@...>

Bug #1773: Gem path doesn't honor user gem?

12 messages 2009/07/14

[#24390] [Feature #1784] More encoding (Big5 series) support? — Lin Jen-Shin <redmine@...>

Feature #1784: More encoding (Big5 series) support?

12 messages 2009/07/16

[#24467] Re: [ruby-cvs:31226] Ruby:r24008 (ruby_1_8_6): Removed private on to_date and to_datetime. — Urabe Shyouhei <shyouhei@...>

Hello.

10 messages 2009/07/21

[#24472] [Feature #1800] rubygems can replace system executable files — Kazuhiro NISHIYAMA <redmine@...>

Feature #1800: rubygems can replace system executable files

13 messages 2009/07/21

[#24530] [Feature #1811] Default BasicSocket.do_not_reverse_lookup to true — Roger Pack <redmine@...>

Feature #1811: Default BasicSocket.do_not_reverse_lookup to true

9 messages 2009/07/23

[#24624] [Bug #1844] Immediates Should Not Respond to :dup — Run Paint Run Run <redmine@...>

Bug #1844: Immediates Should Not Respond to :dup

15 messages 2009/07/30

[ruby-core:24584] Re: [Bug #1525] Deadlock in Ruby 1.9's VM caused by ConditionVariable.wait and fork?

From: "none <" <tetsu.soh.dev@...>
Date: 2009-07-28 03:27:03 UTC
List: ruby-core #24584
Eric Wong wrote:
> Issue #1525 has been updated by Eric Wong.
>
>
> Looking at trunk, there doesn't seem to be any accounting of mutexes to pass to
> handlers for pthread_atfork; so the child process will just inherit the mutexes
> in an unknown state.
>
>   
Yes.
> It should be possible to fix the problem by keeping track of all mutexes as
> they're created/initialized and registering pthread_atfork handlers
> to ensure all mutexes are unlocked when the child starts running.
>
>   
In fact, it is impossible to track all mutexes because the usage of 
mutexes really
depends on the underlying implementation.
For example, the deadlock on this issues doesn't happen on Linux system, 
even
not on FreeBSD7.2, but happens on FreeBSD6.4.

Thanks
-Tetsu


In This Thread