I suppose as a bandaid to the real problem you could have each
programmer include some lib that overwrites require with a thread safe
version that allows at most one thread to be within a require sequence
at a time.  Just thinking out loud.
-=r

On Thu, Dec 25, 2008 at 12:51 AM, Charles Oliver Nutter
<charles.nutter / sun.com> wrote:
> Paul Brannan wrote:
>>
>> Currently in a single-threaded application the above require call is a
>> no-op.  Using a recursive mutex would allow it to continue to be a
>> no-op.
>
> It's not a no-op, though it may seem to be. It still needs to check if the
> resource has been loaded. If the code also clears $" it would continue
> recursively requiring itself forever.
>
> A circular require also appears to be a no-op in 1.8.6 since $" is populated
> immediately before the file begins loading. This is largely why circular
> requires work without infinitely loading the same files. But the problem we
> need to address here is that the resources being defined during require may
> not be finished loading. That's why we need a lock, and since existing code
> already has circular requires in many cases, we can't use a lock per
> resources because that will cause deadlocks.
>
> - Charlie
>
>



-- 
2 Timothy 1:7