From: Brent Roman Date: 2008-12-04T03:17:06+09:00 Subject: [ruby-core:20266] Re: autoload and concurrency +1 Why can't that "special value" be a kind of Mutex? Each thread tries to aquire it. The first succeeds, later threads block. As the later threads unblock, each redundantly "requires" the files needs for the constant, which have just been loaded by the first thread, so all the later threads quickly give up the Mutex and continue. - brent Charles Oliver Nutter-2 wrote: > > > Currently, the basic logic of autoload is like this: > > 1. The special value is removed from the constant table > 2. The associated file is required, and presumably defines the constant > 3. The constant is re-looked-up after the require completes > > The problem lies in step 1 here. There can be a gap between the time the > special value is removed from the constant table and the time the > required file redefines it. During this period, another thread may try > to request the constant value. Since the autoload value has been removed > and the new value has not yet replaced it, the constant search continues > (and eventually fails with a NameError). > > The primary behavioral change needed would be to not remove the autoload > value, or to replace it with a new marker indicating "autoload in > progress". This would require changes to anything that looks up > constants, so it would know not to initiate a new autoload require nor > continue up the constant scope chain but to *block* until the autoload > is complete. I believe this is the only way to make autoload threadsafe. > > I will also agree with Yehuda that a thread-unsafe autoload is broken, > since it means the primary use case of autoload (delayed loading a file > and definition of a constant) can't be used in the presence of threads. > > - Charlie > > > -- View this message in context: http://www.nabble.com/-ruby-core%3A20235--autoload-and-concurrency-tp20806574p20818235.html Sent from the ruby-core mailing list archive at Nabble.com.