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

> * Modify all require implementations to immediately return false if  he requested resource has already been loaded or is in the process  f being loaded. This does not guarantee the file has *completed*  
> loading, but would ensure we do not double-initialize anything in a  equired file. Along with this, we would simply advise all  
> developers to avoid concurrent requires
> * Modify all require implementations to use a global lock,  
> disallowing concurrent requires entirely. This means required files  ust be well-behaved; they can't start up new threads that do  
> requires or perform long-running tasks. It would fix the concurrency  roblem entirely and requires from multiple threads would simply  
> happen in serial.
>
> Both of these require behavioral changes in at least some Ruby  
> versions, with the latter requiring the most drastic changes (since  oncurrent requires will no longer run in parallel, as they do now,  ven if no common resources are in contention).
>
> A third option, having a per-resource lock, is infeasible due to the  trong possibility of deadlocks. If two threads require separate  
> files with circular dependencies, deadlock is almost assured. If  
> this mechanism has been implemented in any versions of Ruby, it  
> should be replaced with either of the two solutions above.


The first solution will not be thread safe, for the reasons statedÍÕhe  
fact that require returns does not mean that the file is actually  
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  
up with any code this could currently break.