From: "Mordeccai (Martin Wein) via ruby-core" <ruby-core@...>
Date: 2026-10-05T03:25:07+00:00
Subject: [ruby-core:126922] [Ruby Feature#11817] map.parallel

Issue #11817 has been updated by Mordeccai (Martin Wein).


I���d like to revive this proposal with a concrete use case I ran into in a Rails application.

I frequently need to perform the same I/O-bound operation concurrently over a collection ��� for example, generating multiple documents through an external API ��� wait until all operations complete, and collect the results in order.

In JavaScript this is straightforward:
<pre>
await Promise.all(items.map(process))
</pre>

In Ruby, this still generally requires a gem and additional machinery. I think Ruby would benefit from a simple standard abstraction such as:
<pre>
items.concurrently { process(it) }
</pre>

or:

<pre>
items.concurrent_map { process(it) }
</pre>

The implementation could use a bounded concurrency mechanism rather than creating one thread per item.

Nearly 11 years after this issue was opened, has Ruby���s concurrency model evolved enough that something like this could now be reconsidered?

----------------------------------------
Feature #11817: map.parallel
https://bugs.ruby-lang.org/issues/11817#change-119305

* Author: eike.rb (Eike Dierks)
* Status: Open
----------------------------------------
I'd like to suggest a new method: #parallel

That method should take care of executing workloads in parallel across multiple cores.

I believe that #map can sometimes be distributed to many simultaneous threads.

So we would spread out the map blocks into parallel processing,
and then collect the results in order.

I believe this would need some new infrastructure like apple did with great_central,
so I'm talking along these lines.
(Aka we only want to open up as many threads as there are cores)

This would not help much with a simple map (because we need to collect and serialize the results in the end)
but it could be cool for more complex mappings.

Maybe this should have been a rails topic first,
because there it might make a lot of sense to render partials in parallel,
this could really speed up rails response rendering ;-)

But I believe this is a topic for ruby in general.
Given that we now go to really many cores,
it should be at the heart of ruby to use that.

For a start we could just declare #parallel as -> return self.
and than improve on it.

A naive implementation would just open a new thread for every parallel map block,
but that would not work well -- it actually would be very slow.

So we actually need a thread management,
along the lines of great central.

I believe this should be built into the very core libs of the ruby language.

I know this is hard stuff, but it needs to be done.
Let's go parallel from the heart of the language.

---


Please let us discuss if adding the #parallel method would be a good idea.
Let's come up with some implementations to find the problems.

I'm explicitly referring to map#parallel here.
In rails that might be cache.parallel (if you followed)

for some math tasks it might also be
   parallel do {}



































-- 
https://bugs.ruby-lang.org/
______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.ruby-lang.org/