From: Jim Deville Date: 2008-12-03T13:27:26+09:00 Subject: [ruby-core:20236] Re: autoload and concurrency --_000_B8A3C6EE027AF84086DD3A049CF34A4A2FB2E9AC38NAEXMSGC112re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This seems like a strong argument in favor of Ruby-core:20225. From: Yehuda Katz [mailto:wycats@gmail.com] Sent: Tuesday, December 02, 2008 8:23 PM To: ruby-core@ruby-lang.org Subject: [ruby-core:20235] autoload and concurrency Merb uses autoload rather extensively. We have lately observed some disturb= ing behavior around concurrency. Effectively, because autoload removes the flag before loading the file, if = two threads concurrently attempt to access an autoloaded constant, one of t= he threads can get a NameError. It's easy to reproduce this by adding a sleep to the file being loaded befo= re the constant is defined, and then spinning up two threads that both try = to use the constant. This is reproducible in MRI; it does not only happen w= ith JRuby's true parallel execution. The worst part is that no user action can solve this problem: because autol= oading is magic, it's impossible for the user to lock the resulting require= . In effect, this makes autoloading completely useless for threaded environ= ments. Is this intentional? Is there something we can do at the language level to ameliorate this probl= em? -- Yehuda Katz Developer | Engine Yard (ph) 718.877.1325 --_000_B8A3C6EE027AF84086DD3A049CF34A4A2FB2E9AC38NAEXMSGC112re_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This seems like a strong argument in favor of Ruby-core:2022= 5.

 

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

 

Merb uses autoload rather extensively. We have lately observed some disturbing behavior around concurrency.

 

Effectively, because autoload removes the flag before loading the file, if two threads concurrently attempt to access an autoload= ed constant, one of the threads can get a NameError.

 

It's easy to reproduce this by adding a sleep to the f= ile being loaded before the constant is defined, and then spinning up two threa= ds that both try to use the constant. This is reproducible in MRI; it does not only happen with JRuby's true parallel execution.

 

The worst part is that no user action can solve this problem: because autoloading is magic, it's impossible for the user to lock= the resulting require. In effect, this makes autoloading completely useless for threaded environments. Is this intentional?

 

Is there something we can do at the language level to ameliorate this problem?


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

--_000_B8A3C6EE027AF84086DD3A049CF34A4A2FB2E9AC38NAEXMSGC112re_--