https://bugs.ruby-lang.org/https://bugs.ruby-lang.org/favicon.ico?17113305112022-07-23T02:34:54ZRuby Issue Tracking SystemRuby master - Feature #18926: Ractor should support mutexes and treat the block as critical section across ractorshttps://bugs.ruby-lang.org/issues/18926?journal_id=984442022-07-23T02:34:54Zianks (Ian Ker-Seymer)
<ul></ul><p>With all due respect for Ractor’s incredible technical achievements so far, I unfortunately think that the “honeymoon phase” for Ractor may be complete. The community was incredibly bullish about its potential and the problems it could solve, but so far it has proven to be too burdensome. I could be misinformed, but I personally don’t know of any serious projects making use of Ractor for this reason.</p>
<p>It’s unfortunate, but not all hope is lost…</p>
<p>I think it would be wise to honestly examine the shortcomings of Ractor. And if needed, entirely re-design to make it more useful to the Ruby community. If that isn’t possible, we should explore ways to communicate the shortcomings, and provide a clear path and solutions for these common issues.</p>
<p>A lot of hard work and technical accomplishments have gone into making Ractor even possible, and I have a deep respect for it. I am just worried Ruby users might lose faith in it.</p> Ruby master - Feature #18926: Ractor should support mutexes and treat the block as critical section across ractorshttps://bugs.ruby-lang.org/issues/18926?journal_id=984452022-07-23T11:40:50ZEregon (Benoit Daloze)
<ul></ul><p>In the example, allowing to mutate <code>@map</code> in a Ractor is fundamentally unsafe, because there could be another reference to <code>@map</code> which is accessed concurrently without the Mutex.<br>
In fact there are two in that example, <code>@map.key?</code> and <code>@map[name]</code> inside <code>get_from_map</code> (and it is not enough to only synchronize the writes).<br>
I don't think it is feasible in Ruby to track all references to an object in any kind of efficient manner, so this seems unfeasible to me at least with a Hash.</p>
<p>IMHO Ractor while fun are incompatible with the vast majority of Ruby code, gems, and many Ruby patterns.<br>
If you want parallel execution of Ruby code compatible with the majority of Ruby code, use Threads on TruffleRuby or JRuby (also avoids the copying/freezing overheads whenever passing an object to another Ractor).</p> Ruby master - Feature #18926: Ractor should support mutexes and treat the block as critical section across ractorshttps://bugs.ruby-lang.org/issues/18926?journal_id=984462022-07-23T11:42:41ZEregon (Benoit Daloze)
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/journals/98446/diff?detail_id=62877">diff</a>)</li></ul> Ruby master - Feature #18926: Ractor should support mutexes and treat the block as critical section across ractorshttps://bugs.ruby-lang.org/issues/18926?journal_id=984712022-07-26T16:40:15Zchucke (Tiago Cardoso)
<ul></ul><blockquote>
<p>In the example, allowing to mutate @map in a Ractor is fundamentally unsafe...</p>
</blockquote>
<p>The proposal is for mutex blocks to synchronize across ractors, thereby making it safe. This would IMO make for a better default than the current one, where mutexes aren't usable across ractors.</p>
<blockquote>
<p>In fact there are two in that example, @map.key? and @map[name] inside get_from_map (and it is not enough to only synchronize the writes).</p>
</blockquote>
<p>You are correct, a simple early-check in the mutex block could have fixed that. It was nonetheless a "naive" illustration of a common pattern seen across a lot of gems, which just can't be replicated, or has to be massively overwritten, using ractors.</p>
<p>My proposals for ractors are all towards making them usable, and diminishing the adoption overhead. I too agree that they're largely unusable in production at the moment, and ractors should perhaps not aim at being so "pure" and follow the erlang processes approach of absolutely no shared memory, and go the way of pragmatism (like go) and provide some escape hatches which make the ruby standard library, as well as a significant chunk of the ecosystem, usable. Then it could focus on being lightweight, provide M:N concurrency, and all of those things that are probably in the roadmap.</p>
<p>I maintain a <a href="https://gitlab.com/honeyryderchuck/httpx/-/merge_requests/211" class="external">branch</a> in my HTTP library, where I track ractor support, and I recently managed to perform an HTTP request inside a ractor. https still does not work, as well as most other features, and a few shortcuts were taken which are definitely not getting merged in the main branch, but still that was progress.</p>
<p>I'll keep using threads in production though, don't worry :)</p>