On Dec 22, 2008, at 10:50 AM, Charles Nutter wrote:

> * Modify all require implementations to immediately return false if =20=

> the requested resource has already been loaded or is in the process =20=

> of being loaded. This does not guarantee the file has *completed* =20
> loading, but would ensure we do not double-initialize anything in a =20=

> required file. Along with this, we would simply advise all =20
> developers to avoid concurrent requires
> * Modify all require implementations to use a global lock, =20
> disallowing concurrent requires entirely. This means required files =20=

> must be well-behaved; they can't start up new threads that do =20
> requires or perform long-running tasks. It would fix the concurrency =20=

> problem entirely and requires from multiple threads would simply =20
> happen in serial.
>
> Both of these require behavioral changes in at least some Ruby =20
> versions, with the latter requiring the most drastic changes (since =20=

> concurrent requires will no longer run in parallel, as they do now, =20=

> even if no common resources are in contention).
>
> A third option, having a per-resource lock, is infeasible due to the =20=

> strong possibility of deadlocks. If two threads require separate =20
> files with circular dependencies, deadlock is almost assured. If =20
> this mechanism has been implemented in any versions of Ruby, it =20
> should be replaced with either of the two solutions above.


The first solution will not be thread safe, for the reasons stated=97the =
=20
fact that require returns does not mean that the file is actually =20
loaded. This would lead to hard-to-diagnose problems.

I think the global lock is the way to go. And I find it hard to come =20
up with any code this could currently break.


Dave=