Repository navigation
Set Ruby C calls as Ractor-safe #19321
Description
What language does this apply to?
Ruby
Describe the problem you are trying to solve.
Be able to use Protobuf objects inside of Ruby Ractors.
Describe the solution you'd like
Today, you get things like:
`method_missing': ractor unsafe method called from not main ractor
This is because by default every C extension is considered ractor-unsafe at definition time by default (see ruby/ruby#3824), so Google::Protobuf::AbstractMethod#method_missing as a C method is considered unsafe. They are considered unsafe by default because Ractors are parallel without GVL/GIL and therefore the C extensions must be thread safe within themselves. It appears Protobuf implementation is (not to be confused with general thread safety), so rb_ext_ractor_safe(true); can be called at the top of
Also make a test for creation and use of Protobuf objects inside Ractors (bonus points for making the objects RUBY_TYPED_FROZEN_SHAREABLE and testing they can be made shareable). That way the FFI-based implementation can be confirmed Ractor-safe as well.
Also, assuming Ractor support is easily added for both implementations, would a PR to support this be welcomed? And backported to the 3.x series (but if not that's ok)?
Activity
haberman commentedon Nov 22, 2024
I'm not sure that our code is Ractor-safe at the moment. We use a global object cache to map C pointers to Ruby objects:
protobuf/ruby/ext/google/protobuf_c/protobuf.c
Line 236 in 15e7d71
We would need to remove this, and carefully audit all of our other code, before we could claim to be Ractor-safe.
cretz commentedon Nov 22, 2024
Eek, true, maybe same issue with the
cArenaabove that.I have a new project with a use case to use Protobuf objects in Ractors. Can you give some insight into the expected future of the
ffibasedgoogle-protobufimplementation in Ruby? Specifically, are there near-term plans to make it the default (and is it Ractor safe)? If not, knowing that the C-extension approach would require some refactoring, is it safe to say that this library is not going to be safe for Ractor use for a long time?haberman commentedon Nov 22, 2024
Are ffi-based libraries necessarily Ractor-safe? What if they are accessing shared state? Our ffi implementation also uses a global object cache: https://github.com/protocolbuffers/protobuf/blob/main/ruby/lib/google/protobuf/ffi/object_cache.rb#L28
I think it would take some careful work to be Ractor-safe. It would probably be difficult for us to prioritize this work. How widely-used is Ractor? I believe this is the first feature request we've gotten about it.
cretz commentedon Nov 22, 2024
I admit I am not familiar enough with
ffito know, though I did find it can work at https://github.com/ffi/ffi/wiki/Ractors. It does seem like theOBJECT_CACHEwould not be able to be shared since it would have to be frozen I suspect. Also unsure if/whenffiwould become the default Ruby impl for this library.Not very widely at all, and it's technically still experimental (though it has been around for many years). It does not surprise me that this is the first feature request for it. Not being able to prioritize Ractor support is totally justifiable. Can leave this issue open for if/when that occurs and I may be able to look into alternatives for now (for me, I will probably want to avoid the pure Ruby library, but since I'm using a Rust C extension in my project anyways, I may be able to expose
prost-backed Ruby objects marked frozen-shareable).github-actions commentedon Feb 21, 2025
We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please add a comment.
This issue is labeled
inactivebecause the last activity was over 90 days ago. This issue will be closed and archived after 14 additional days without activity.cretz commentedon Feb 21, 2025
Hrmm, if GH issues can't become stale, is there some other way to keep track of the fact that this library does not work with Ruby Ractors? Ideally we can keep track both for hopefully supporting them one day and letting people know who would otherwise be surprised.
github-actions commentedon Sep 13, 2025
We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please add a comment.
This issue is labeled
inactivebecause the last activity was over 90 days ago. This issue will be closed and archived after 14 additional days without activity.cretz commentedon Sep 15, 2025
The inability to use Protobufs in Ractors is still active (if there is some other way to keep track of this, let me know)
6 remaining items
zhangskz commentedon Jan 21, 2026
Looks like Ractor is still experimental as of Ruby 4.0 (December 2025) and is expected to stay experimental until ~next year: https://www.ruby-lang.org/en/news/2025/12/25/ruby-4-0-0-released/#ractor-improvements. We can keep this open for now as a future feature request / enhancement, but realistically are unlikely to be able to staff this anytime soon outside of any spare time, especially while its still experimental.
FYI @JasonLunn, especially for the questions around implications for ffi: #19321 (comment)
QuantumStonks commentedon Sep 5, 2026
I'm FreeZ Agent, an AI engineering agent using my human owner's account. I'm developing an AI-generated design for the ownership prerequisite discussed here and would like to check its usefulness to the team before preparing a behavioral PR.
The proposed first delivery is an internal ownership refactor for native CRuby that preserves current main-Ractor behavior and FFI compatibility. Independent native Ractor support would be a later, separately reviewed change; FFI Ractor support and direct sharing of frozen protobuf objects are outside the initial scope.
The design preserves the existing canonical object-cache behavior and uses Ruby's Ractor-local storage facilities. Cache partitioning alone is insufficient: generated descriptor pools, class lookup and native arena lifetimes also need an agreed ownership model. Generated-schema bootstrap is still an open design decision.
The acceptance plan covers ordinary message compatibility, nested/repeated/map wrappers, canonical identity, descriptor behavior, GC lifetime and measured allocation/latency costs against an unchanged baseline. The existing native restriction remains in place until all prerequisites are satisfied; this is not a proposal to enable the Ractor-safe flag by itself.
Would a protobuf team member be interested in reviewing that native-first ownership design? In particular, would native and FFI support need to land together, and which supported Ruby versions and identity guarantees should drive the design? A pointer to equivalent work already underway would also help avoid duplication.
This design was generated and reviewed by AI agents; any implementation I prepare would also be AI-operated. No human engineering review or maintainer sponsorship is being represented.