https://redmine.ruby-lang.org/https://redmine.ruby-lang.org/favicon.ico?17113305112012-11-25T09:55:40ZRuby Issue Tracking SystemRuby master - Feature #7429: Provide options for core collections to customize behaviorhttps://redmine.ruby-lang.org/issues/7429?journal_id=338342012-11-25T09:55:40Zmame (Yusuke Endoh)mame@ruby-lang.org
<ul><li><strong>Tracker</strong> changed from <i>Bug</i> to <i>Feature</i></li></ul><p>Too late completely, as you said.</p>
<p>--<br>
Yusuke Endoh <a href="mailto:mame@tsg.ne.jp" class="email">mame@tsg.ne.jp</a></p> Ruby master - Feature #7429: Provide options for core collections to customize behaviorhttps://redmine.ruby-lang.org/issues/7429?journal_id=338572012-11-25T21:54:05Zmatz (Yukihiro Matsumoto)matz@ruby.or.jp
<ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Rejected</i></li></ul><p>Even though I prefer smaller set of built-in fundamental classes, I don't think 'concurrent' option is sufficient,<br>
since it requires totally different implementation. I think it's rather better for you to propose 'ParallelHash' etc.</p>
<p>Matz.</p> Ruby master - Feature #7429: Provide options for core collections to customize behaviorhttps://redmine.ruby-lang.org/issues/7429?journal_id=338602012-11-25T23:19:47Ztrans (Thomas Sawyer)
<ul></ul><p>=begin<br>
I wonder if concurrency behavior can be designed as a mixin. As long as the underlying class conforms to its interface then "ParallelWhatever" becomes possible. ParallelHash would then not be needed as a built-in class b/c it would be simple to define.</p>
<p>class MyParallelHash < Hash<br>
include Concurrency<br>
end</p>
<p>=end</p> Ruby master - Feature #7429: Provide options for core collections to customize behaviorhttps://redmine.ruby-lang.org/issues/7429?journal_id=338652012-11-26T03:23:07Zheadius (Charles Nutter)headius@headius.com
<ul></ul><p>matz (Yukihiro Matsumoto) wrote:</p>
<blockquote>
<p>Even though I prefer smaller set of built-in fundamental classes, I don't think 'concurrent' option is sufficient,<br>
since it requires totally different implementation. I think it's rather better for you to propose 'ParallelHash' etc.</p>
</blockquote>
<p>That was indeed my intention; concurrent: true would allow using a completely different implementation under the covers, allowing for an efficient concurrent hash/array (rather than one that simply locks on all accesses).</p>
<p>I will repropose as new collection types. Is there any chance of getting them into 2.0.0?</p> Ruby master - Feature #7429: Provide options for core collections to customize behaviorhttps://redmine.ruby-lang.org/issues/7429?journal_id=338662012-11-26T03:26:27Zheadius (Charles Nutter)headius@headius.com
<ul></ul><p>trans (Thomas Sawyer) wrote:</p>
<blockquote>
<p>I wonder if concurrency behavior can be designed as a mixin. As long as the underlying class conforms to its interface then "ParallelWhatever" becomes possible. ParallelHash would then not be needed as a built-in class b/c it would be simple to define.</p>
<p>class MyParallelHash < Hash<br>
include Concurrency<br>
end</p>
</blockquote>
<p>Actually, JRuby already provides this as JRuby::Synchronized:</p>
<p>class MyParallelHash < Hash<br>
include JRuby::Synchronized<br>
end</p>
<p>It's rather hacky though for a few reasons:</p>
<ul>
<li>In JRuby, the JRuby::Synchronized module inserts itself into the method lookup process, returning all methods wrapped with synchronization against the target object.</li>
<li>The synchronization is very coarse-grained and much slower than other implementations of a concurrent data structure that would use fewer (or no) locks.</li>
<li>It is not common to have the inclusion of a module change the nature of every method in the host class.</li>
</ul>
<p>It would be better if we had some fast, always-concurrent data structures built in.</p> Ruby master - Feature #7429: Provide options for core collections to customize behaviorhttps://redmine.ruby-lang.org/issues/7429?journal_id=338672012-11-26T03:44:22Ztrans (Thomas Sawyer)
<ul></ul><p>That is interesting. I suspect part of the problem is the design of the Hash class itself --something I addressed before in <a class="issue tracker-2 status-7 priority-4 priority-default closed" title="Feature: CRUDify Hash class (Feedback)" href="https://redmine.ruby-lang.org/issues/6442">#6442</a>. If Hash had a core set of non-reducible methods which all the others depended, then those should be the only methods that would need to be targeted. Also, #prepend might be handy here, rather than "inserts itself into the method lookup process".</p>
<p>Speed isn't everything. I think good design is at least, if not more, important.</p> Ruby master - Feature #7429: Provide options for core collections to customize behaviorhttps://redmine.ruby-lang.org/issues/7429?journal_id=338682012-11-26T03:57:01Zheadius (Charles Nutter)headius@headius.com
<ul></ul><p>Speed isn't everything...until it becomes everything. Ruby should not be wasteful unnecessarily. There are also immutable truths about data structure implementation, like the fact that adding thread-safety to most data structures comes at a cost...which is why in JRuby we decided not to make Hash and Array thread-safe by default.</p>
<p>There are also a limited set of data structures that make unsynchronized reads concurrent with writes safe. You usually have to have a data structure that's designed to do both safely or they both have to be synchronized.</p>
<p>For Hash at least, I think something like a CTrie (concurrent hash array mapped trie) would be a nice choice. It's not O(1) but it's pretty good.</p> Ruby master - Feature #7429: Provide options for core collections to customize behaviorhttps://redmine.ruby-lang.org/issues/7429?journal_id=338792012-11-26T07:39:52Zmatz (Yukihiro Matsumoto)matz@ruby.or.jp
<ul></ul><p><a class="user active user-mention" href="https://redmine.ruby-lang.org/users/286">@headius (Charles Nutter)</a> I am afraid it's not going to 2.0, for some reasons:</p>
<ul>
<li>it's too late to add new classes to 2.0</li>
<li>and it will take more time to prepare parallel collection implementation for other Ruby (in this case mainly CRuby).</li>
<li>the future CRuby will lean toward non threading way, e.g, Actors.</li>
</ul>
<p>Matz.</p> Ruby master - Feature #7429: Provide options for core collections to customize behaviorhttps://redmine.ruby-lang.org/issues/7429?journal_id=339622012-11-27T00:26:48Zheadius (Charles Nutter)headius@headius.com
<ul></ul><p>matz (Yukihiro Matsumoto) wrote:</p>
<blockquote>
<p><a class="user active user-mention" href="https://redmine.ruby-lang.org/users/286">@headius (Charles Nutter)</a> I am afraid it's not going to 2.0, for some reasons:</p>
<ul>
<li>it's too late to add new classes to 2.0</li>
<li>and it will take more time to prepare parallel collection implementation for other Ruby (in this case mainly CRuby).</li>
</ul>
</blockquote>
<p>In CRuby, with the GIL, you can pretend the existing ones are parallel-safe, can't you?</p>
<blockquote>
<ul>
<li>the future CRuby will lean toward non threading way, e.g, Actors.</li>
</ul>
</blockquote>
<p>If those actors are going to run in parallel, you'll still need to have parallel-safe collections to pass between them...or an explicit mechanism for preventing users from passing mutable state between actors.</p> Ruby master - Feature #7429: Provide options for core collections to customize behaviorhttps://redmine.ruby-lang.org/issues/7429?journal_id=420102013-09-27T01:02:30Zdsisnero (Dominic Sisneros)dsisnero@gmail.com
<ul></ul><p>Maybe combine it with <a href="https://bugs.ruby-lang.org/issues/8909" class="external">https://bugs.ruby-lang.org/issues/8909</a><br>
options = {klass:Hamster}</p>
<p>{ bug_number: 7429, status: maybe}.f(options)</p>
<p>node_option = {f:deep , size: 2}<br>
[:add, [:left, :right]].f( f:node_option)</p>