3 ms·
No news about Ractors! The new concurrency facilities that Ruby 3.0 introduced. Anyone has an insight if there was any further development on that front?
by geospeck 5y ago
No news about Ractors! The new concurrency facilities that Ruby 3.0 introduced. Anyone has an insight if there was any further development on that front?
- ksec 5y agoCorrect me if I am wrong but I dont think much has happened in terms of Ractors. But lots of work happening on Fiber and Async. Edit: LOL ko1 replied [1] on Twitter "ごめんよ。来年頑張るよ " / "Sorry. I'll do my best next year". @ko1: Thanks for all your work on Ruby. [1] https://twitter.com/_ko1/status/1474769727109353474 https://twitter.com/_ko1/status/1474769727109353474
- byroot 5y agoTons have happened in stabilizing them, 3.0 had lots of Ractor related bugs. But no new Ractors related features no.
- Lammy 5y agoIMO the most impactful improvement for Ractors right now needs to come from the community, because third-party Gems with C-extensions need to explicitly opt themselves in as Ractor-safe: https://docs.ruby-lang.org/en/master/doc/extension_rdoc.html#label-Appendix+F.+Ractor+support https://docs.ruby-lang.org/en/master/doc/extension_rdoc.html... "By default, all C extensions are recognized as Ractor-unsafe. If C extension becomes Ractor-safe, the extension should call `rb_ext_ractor_safe(true)` at the `Init_` function and all defined method marked as Ractor-safe. Ractor-unsafe C-methods only been called from main-ractor. If non-main ractor calls it, then `Ractor::UnsafeError` is raised." I've submitted a few such patches for my own personal use, and it's a very trivial change for extensions which keep no state in C-land that would need to be synchronized between Ractors, e.g. https://github.com/dearblue/ruby-extattr/pull/1 https://github.com/dearblue/ruby-extattr/pull/1