ì ÄÚ, 21/10/2008 Û 23:46 -0700, rogerdpack Ô¥¯ý:
> > Reloading isn'tthreadsafeand *can't* be due to the way constant
> > definition works in ruby. Why are you doing it in production mode?
> > allow_concurrency should be false for development mode? Is itnot?
I'm curious about the "constant definition not being threadsafe" -- is
this a thread safe bug in MRI?
One of the problems here is that the class which is being defined is
visible in other threads. So threads may see partially defined classes.
This is very hard to fix. And it's indeed ruby's (not just MRI, I
In MRI it is possible to stop all other threads (by setting
Thread.critical) and Rails could try to solve this problem by holding
this flag around #load and #require. But this is not a proper solution,
because Thread.critical is implementation-specific feature and sooner or
later ruby will need to get rid of it. And it should be noted that even
this solution may fail if fancy things is tried during load. For example
if it tries to lock some mutex, which is locked by some other thread.
fyi: Here's a pointer to a recent thread among the jruby developers about a similar issue:
'require' thread safety?
Basically what should require do when the same library is loaded by two or more threads?
The problem is that after the first "require 'mylib'" starts (but before it has finished evaluating the code) what should ruby do when a script in a second thread evaluates: "require 'mylib'".
They decided to:
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