From: Charles Oliver Nutter <headius@...>
Date: 2011-11-19T06:31:27+09:00
Subject: [ruby-core:41142] Re: [Backport93 - Backport #5621] Please backport thread-safe autoloading patch

On Fri, Nov 18, 2011 at 12:15 AM, Hiroshi Nakamura <nahi@ruby-lang.org> wrote:
> Sure. ��This deadlock from cross-require is intentional at this moment
> I believe, and that's the reason for the warning 'loading in progress,
> circular require considered harmful'. ��Related discussion is at #920.
>
> I don't know how Java's classloader avoids this problem.

Each classloader has a single lock, and if it needs to call a parent
classloader the locks are still always acquired in the same order
(meaning deadlock is impossible).

>> Yehuda's simple case could be solved by having all autoloads
>> synchronized against a single lock; only *either* the Foo autoload
>> or the Bar autoload could fire, and then the other would fire once
>> it had completed.
>
> I understand that it's not an autoload issue but a concurrent require
> issue, and 'disallowing concurrent requires entirely' in #920 is hard
> jump for Ruby...
>
> So I hope someone extract requirements from Yehuda's case for solving
> Rails' issue, not by changing require/autoload directly. ��I don't have
> enough time for it now but there would be some more related
> assumptions around it I guess. ��For example, they don't want to let
> developers write 'require' explicitly, a convention for Ruby's module
> hierarchy that must sync with filesystem layout, etc...

I don't see how it can be fixed if concurrent requires are allowed,
but individual files have their own locks. If there's ever any
potential for two different locks to be acquired by two threads in
opposing order, it can deadlock.

You're right, though...it's important to point out Yehuda's problem is
not an autoload problem. Autoload thread-safety itself is achievable.
Require thread-safety doesn't exist even today. That's the real
problem.

- Charlie