I think there's a strong argument that you have no guarantee after
calling require and receiving "false" that the library has *completed*
loading, only that someone else has *initiated* a load. It's certainly a
bad pattern to be doing requires in many threads, and I don't personally
believe there's any level of locking or synchronization that would
safely guarantee a require that's started has completed before someone
tries to use the code in that library.
I'd love to be proven wrong, but all the scenarios and solutions
proposed so far to cause a require to block are certainly going to be
deadlock-prone. I think our best be now is definitely (2), to at least
guarantee that a given library can't be require'd twice, even if we
can't guarantee across threads that once require returns false the
target library is ready for use.
Nick Sieger wrote:
Seems like we'd need some form of (3) in order for any synchronization
to work properly, because a thread can't go ahead and continue
executing and expect to work until the code is fully loaded by the
other thread.
Is it safe to assume that most of the time, require is used to load
library code and not to continue the flow of execution in long-running
scripts? Because then to avoid deadlock we could have a thread that
discovers another thread is already loading the same library to wait
with a reasonable timeout. Would that scenario of mulitple threads
requiring the same code happen rarely enough that this would be a
strategy worth following?
/Nick
On Wed, Oct 15, 2008 at 2:11 PM, Thomas E Enebo <[EMAIL PROTECTED]> wrote:
Keep a list of currently loading scripts and then have
second/additional requires (note load may be different) of same file
block until just that require finishes. Deadlocks do seem possible:
a.rb
require 'b'
b.rb
require 'a'
Thread 1: require 'a'
Thread 2: require 'b'
I have nothing concrete, but I think it is possible to work around
this somehow? I also wonder how rare this is.
-Tom
On Wed, Oct 15, 2008 at 2:23 AM, Charles Oliver Nutter
<[EMAIL PROTECTED]> wrote:
I've got a question about require thread safety: should we try to enforce
it?
For example, if two scripts try to require the same file at once, should we:
1. do what we do now, and potentially they both execute the file
2. synchronize against the list of loaded features, such that they may both
search for the library but only one will load it; however, this won't
guarantee the library has been *completely* loaded
3. synchronize against both the list of loaded features and any features
still in the process of loading; this guarantees that require will never
re-load a script and will not return until any other requires on other
threads have completed; but it may lead to deadlocks if two threads attempt
to load the same two libraries in different orders.
At the moment I'm leaning toward improving the situation at least to (2)
above, but not doing (3) because MRI makes no such guarantees and the
deadlock potential is too high. Am I right about that? Other thoughts?
- Charlie
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
--
Blog: http://www.bloglines.com/blog/ThomasEEnebo
Email: [EMAIL PROTECTED] , [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
