summaryrefslogtreecommitdiff
path: root/ChangeLog
diff options
context:
space:
mode:
authorshyouhei <shyouhei@b2dd03c8-39d4-4d8f-98ff-823fe69b080e>2011-06-02 10:02:20 +0000
committershyouhei <shyouhei@b2dd03c8-39d4-4d8f-98ff-823fe69b080e>2011-06-02 10:02:20 +0000
commit61ac67c14b03d52826b08ce89bb03a188dbfd6c3 (patch)
treead63ff20dd63df63b25dcb3c55c89cff66b7e822 /ChangeLog
parent6e96241d318cf4a177c4ed59ea334cb687f4efd6 (diff)
merge revision(s) 31731:31734:
* variable.c (rb_autoload_load): There is a race condition while autoloading. When two or more threads touch a single autoloaded constant at a time, one of them does the require, but others behave oddly. To fix this situation we now refrain from deleting the autoload table while someone is doing the autoload. That deletion is deferred to a point where a require ended successfully. Doing so make it possible for multiple threads to enter autoloading at the same time but the require is protected against multiple simultaneous entrance anyway so all but one thread gets blocked at that point. So with it, touching a constant that gets autoloaded cause those threads to block until there is another one that does the same thing. [ruby-core:36308] (#921) * variable.c (rb_const_get_0): ditto. * variable.c (autoload_node): ditto. * variable.c (autoload_delete): ditto. git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/branches/ruby_1_8@31732 b2dd03c8-39d4-4d8f-98ff-823fe69b080e Signed-off-by: URABE, Shyouhei <shyouhei@ruby-lang.org> * variable.c (rb_const_get_0): Fix previous change. There were possibilities when an autoload-specified library lacks definition of the constant it was bound to. Once after such library had already beed loaded, the autoload engine shall not reload it. Instead the interpreter have to consider such constant nonexistent. It results in a const_missing situation. * variable.c (rb_autoload_load): ditto. * variable.c (autoload_node): ditto. git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/branches/ruby_1_8@31734 b2dd03c8-39d4-4d8f-98ff-823fe69b080e Signed-off-by: URABE, Shyouhei <shyouhei@ruby-lang.org> git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/branches/ruby_1_8_7@31904 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Diffstat (limited to 'ChangeLog')
-rw-r--r--ChangeLog35
1 files changed, 35 insertions, 0 deletions
diff --git a/ChangeLog b/ChangeLog
index 95aeda318e..92b1334eb7 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,38 @@
+Thu Jun 2 18:33:51 2011 URABE Shyouhei <shyouhei@ruby-lang.org>
+
+ * variable.c (rb_const_get_0): Fix previous change. There were
+ possibilities when an autoload-specified library lacks
+ definition of the constant it was bound to. Once after such
+ library had already beed loaded, the autoload engine shall not
+ reload it. Instead the interpreter have to consider such
+ constant nonexistent. It results in a const_missing situation.
+
+ * variable.c (rb_autoload_load): ditto.
+
+ * variable.c (autoload_node): ditto.
+
+Thu Jun 2 18:28:58 2011 URABE Shyouhei <shyouhei@ruby-lang.org>
+
+ * variable.c (rb_autoload_load): There is a race condition while
+ autoloading. When two or more threads touch a single autoloaded
+ constant at a time, one of them does the require, but others
+ behave oddly. To fix this situation we now refrain from
+ deleting the autoload table while someone is doing the autoload.
+ That deletion is deferred to a point where a require ended
+ successfully. Doing so make it possible for multiple threads to
+ enter autoloading at the same time but the require is protected
+ against multiple simultaneous entrance anyway so all but one
+ thread gets blocked at that point. So with it, touching a
+ constant that gets autoloaded cause those threads to block until
+ there is another one that does the same thing.
+ [ruby-core:36308] (#921)
+
+ * variable.c (rb_const_get_0): ditto.
+
+ * variable.c (autoload_node): ditto.
+
+ * variable.c (autoload_delete): ditto.
+
Mon May 30 10:58:17 2011 Hiroshi Nakamura <nahi@ruby-lang.org>
* lib/logger.rb (Logger::ProgName): do not depend on subversion