Open mohamedhafez opened 3 weeks ago
👋 Nokogiri maintainer here, I'm a Truffleruby contributor and supporter. Nokogiri is a large library, but I would like to make it better support ractors, so please consider my request in that issue to be: what specific use cases should we start with? If you're a user of ractors I'd love to chat with you about your concrete needs.
@flavorjones So I'm not using Ractors, but in JRuby I have multiple threads repeatedly scraping the account pages of substitute teachers looking for newly posted available jobs at their school district (with the explicit, contractual permission of all parties involved). Each thread has it's own Nokogiri object, and is processing different document objects. I want each thread to be able to run with true concurrency, in parallel on different cores of a CPU, without locking globally each time a call is made into the Nokogiri C-extension (as is currently the case when I run the code with TruffleRuby).
In C-Ruby, I would be trying to accomplish the exact same thing but with Ractors instead of threads. However that is not possible because Nokogiri objects can't be used inside of a Ractor currently and throws an error if you try (see https://github.com/sparklemotion/nokogiri/discussions/3283#discussioncomment-9974494)
In planning ahead to the near future when TruffleRuby can run C-extensions marked with
rb_ext_ractor_safe(true)
in parallel, I've been raising issues in common gems to try to nudge them to make their C-extensions Ractor-safe (most already are), and then submitting PR's to mark them asrb_ext_ractor_safe(true)
. This issue will track the progress of all those issues.Still need to be reviewed for Ractor-safety
Reviewed for Ractor-safety, waiting for PR none currently
Reviewed for Ractor-safety, PR submitted
PR merged! 🎉
Gems that will need some work before we can set
rb_ext_ractor_safe(true)
https://github.com/ruby/nkf/issues/21 Needs work on upstream C library, see discussion in https://github.com/ruby/nkf/pull/19
https://github.com/sparklemotion/nokogiri/discussions/3283 Possibly some changes needed to conditionally use threadsafe features of libxml if it's using a new enough version. Testing with
--cexts-lock=false
doesn't have any issues on my app personally though, so a promising sign at leasthttps://github.com/ruby/syslog/issues/10