[Ironruby-core] Code Review: StringGsubEach
Shri.Borde at microsoft.com
Wed Jul 9 02:26:53 EDT 2008
Why isn't MutableString.version called MutableString.Version? That would be the consistent naming convention, right?
The current versioning implementation is not thread-safe. A thread-safe implementation would require using InterlockedCompareAndExchange to update version, right? If we are deferring nailing of the threading story, do we have a bug to track the issue so that we can revisit this?
Similarly, what is the semantics of freezing? The MutableStringOps methods like Append call MutableStringOps.RequireNotFrozenAndIncrVersion and then do the update without a lock. Since atomicity is not guaranteed, there could be race with another thread freezing the object half way through the update which could result in weird behavior (for eg, if the update is a multiple step operation).
This change does not have to be blocked on this issue, but if we can decide how we want thread-safety to work, we can start acting on it instead of building up debt in the library.
Should incrementing the version check for overflow? If not, a comment would be useful to make the intent obvious that overflow would cause an issue only in extreme cases that will surely never happen for real since most updates will be pretty quick. OTOH, if any of the updates runs user code, then overflow is a real issue, though still quite unlikely.
Can MutableStringOps.RequireNotFrozenAndIncrVersion and MutableStringOps.RequireNoVersionChange be methods on MutableString? Inspecting/updating the version outside of MutableString seems to break the encapsulation pretty badly.
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Curt Hagenlocher
Sent: Monday, July 07, 2008 11:01 PM
To: ironruby-core at rubyforge.org; IronRuby External Code Reviewers
Subject: Re: [Ironruby-core] Code Review: StringGsubEach
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Dave Remy
Sent: Monday, July 07, 2008 5:29 PM
To: IronRuby External Code Reviewers
Cc: ironruby-core at rubyforge.org
Subject: [Ironruby-core] Code Review: StringGsubEach
tfpt review "/shelveset:StringGsubEach;REDMOND\dremy"
Changes to for string.gsub and string.each (and each_line) to run clean. The most significant change is to track version in MutableString. This version is bumped on any mutation and functions that iterate (each, each_line, gsub) check the version before and after to assure there has been no version change during the iteration. After these changes all gsub, each, and each_line specs run clean (no excludes). Note that although the specs run clean the each behavior does not match MRI. The spec test contains a new line in the iterating string ("hello\nworld") and MRI does throw a runtime exception if this string is iterated. However if there is no new line in the string MRI does not throw an exception if the underlying string is mutated. This seems inconsistent but worth noting.
String#gsub with pattern and block sets $~ for access from the block
String#gsub with pattern and block restores $~ after leaving the block
String#gsub with pattern and block sets $~ to MatchData of last match and nil when there's none for access from outside
String#gsub with pattern and block raises a RuntimeError if the string is modified while substituting
String#each raises a RuntimeError if the string is modified while substituting
String#each_line raises a RuntimeError if the string is modified while substituting
Ironruby-core mailing list
Ironruby-core at rubyforge.org
More information about the Ironruby-core