From: Tomas Matousek Date: 2008-12-03T14:48:53+09:00 Subject: [ruby-core:20247] Re: autoload and concurrency --_000_F58FE69873E2D5459B72C347DE1582412B2270040CNAEXMSGC112re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think it has already been concluded that autoload and require are inheren= tly broken in presence of threads. See ruby-core:19860. Or am I missing something? Tomas From: Yehuda Katz [mailto:wycats@gmail.com] Sent: Tuesday, December 02, 2008 9:10 PM To: ruby-core@ruby-lang.org Subject: [ruby-core:20245] Re: autoload and concurrency Also, this just illustrates that it's possible. In the case of Merb, we are= n't doing any hanky panky, and still get the bad behavior from time to time= under high concurrency on JRuby. -- Yehuda On Tue, Dec 2, 2008 at 8:58 PM, Charles Oliver Nutter > wrote: Charles Oliver Nutter wrote: Jim Deville wrote: This seems like a strong argument in favor of Ruby-core:20225. Fixing autoload to call require doesn't solve anything because there's stil= l the exact same gap between the time it deletes the special value and the = time when the required file redefines it. A trivial example autoloaded.rb: sleep 1 Bar::Foo =3D 1 autoloader.rb: module Bar autoload :Foo, 'autoloaded.rb' end t1 =3D Thread.new { Bar::Foo } t2 =3D Thread.new { Bar::Foo } t1.join; t2.join Fails every time. Of course "sleep 1" is a longer delay than you'd typicall= y see from requiring in a file, but any delay means there's a change anothe= r thread will schedule and see the missing constant before it's defined. Now some of you may be saying "don't do that". But of course, the developer= accessing the constant *doesn't know* not to do it, and the developer writ= ing the library containing the autoload just wants to defer a require. Who = is breaking the rules? - Charlie -- Yehuda Katz Developer | Engine Yard (ph) 718.877.1325 --_000_F58FE69873E2D5459B72C347DE1582412B2270040CNAEXMSGC112re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think it has already been concluded that autoload and requ= ire are inherently broken in presence of threads. See ruby-core:19860.

Or am I missing something?

 

Tomas

 

From: Yehuda Katz [mailto:wycats@gmail.com]
Sent: Tuesday, December 02, 2008 9:10 PM
To: ruby-core@ruby-lang.org
Subject: [ruby-core:20245] Re: autoload and concurrency

 

Also, this just illustrates that it's possible. In the= case of Merb, we aren't doing any hanky panky, and still get the bad behavior fr= om time to time under high concurrency on JRuby.

 

-- Yehuda

On Tue, Dec 2, 2008 at 8:58 PM, Charles Oliver Nutter = <charles.nutter@sun.com> wrote= :

Charles Oliver Nutter wrote:

Jim Deville wrote:

This seems like a strong argument in favor of Ruby-core:20225.


Fixing autoload to call require doesn't solve anything because there's stil= l the exact same gap between the time it deletes the special value and the ti= me when the required file redefines it.

 

A trivial example

autoloaded.rb:

sleep 1
Bar::Foo =3D 1

autoloader.rb:

module Bar
 autoload :Foo, 'autoloaded.rb'
end

t1 =3D Thread.new { Bar::Foo }
t2 =3D Thread.new { Bar::Foo }
t1.join; t2.join

Fails every time. Of course "sleep 1" is a longer delay than you'= d typically see from requiring in a file, but any delay means there's a chang= e another thread will schedule and see the missing constant before it's defin= ed.

Now some of you may be saying "don't do that". But of course, the developer accessing the constant *doesn't know* not to do it, and the devel= oper writing the library containing the autoload just wants to defer a require. = Who is breaking the rules?

- Charlie




--
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325

--_000_F58FE69873E2D5459B72C347DE1582412B2270040CNAEXMSGC112re_--