[ruby-core:100795] [Ruby master Feature#17307] A way to mark C extensions as thread-safe, Ractor-safe, or unsafe

Issue #17307 has been updated by aardvark179 (Duncan MacGregor).


I talked this over with Eregon yesterday in the context of doing this work in TruffleRuby, and we came to the conclusion that there is a real advantage in being able to selectively mark methods and procedures as thread safe or not. For example a database gem might not be able to declare itself fully thread safe as a whole, but still be able to get significant benefit from marking all the methods used to access individual fields in a record as thread safe so that they could be run while another thread is in the process of executing a different query. My gut feeling would be that very few C extensions could be marked as entirely thread safe, and it would take significant engineering effort to make get them to that that state. This would mean we'd want calls in the init function that look something like
``` c
static VALUE foo(VALUE self) {
  ...
}

static VALUE bar(VALUE self) {
  ...
}

void Init_foo(void) {
  rb_mark_declarations_as_thread_safe(true);
  rb_mark_declarations_as_ractor_safe(true);

  VALUE cMyClass = rb_define_class("MyClass", rb_cObject);
  rb_define_method(cMyClass, "foo", foo, 0); // foo() can be executed in parallel safely

  rb_mark_declarations_as_thread_safe(false);
  rb_mark_declarations_as_ractor_safe(false);

  rb_define_method(cMyClass, "bar", bar, 0); // foo() cannot be executed in parallel safely
}
```

There are some places where we would have to make decisions about how things behave. If you are defining a proc or method from a C extension does its thread safety depend on the method defining it, should the `rb_mark_declaration...` functions be called explicitly, or should we provide new APIs for defining procs and methods?


----------------------------------------
Feature #17307: A way to mark C extensions as thread-safe, Ractor-safe, or unsafe
https://bugs.ruby-lang.org/issues/17307#change-88438

* Author: Eregon (Benoit Daloze)
* Status: Open
* Priority: Normal
----------------------------------------
I would like to design a way to mark C extensions as thread-safe, Ractor-safe, or unsafe (= needs process-global lock).
By default, if not marked, C extensions would be treated as unsafe for compatibility.

Specifically, TruffleRuby supports C extensions, but for scalability it is important to run at least some of them in parallel (e.g., HTTP parsing in Puma).
This was notably mentioned in my [RubyKaigi talk](https://speakerdeck.com/eregon/running-rack-and-rails-faster-with-truffleruby?slide=17).
TruffleRuby defaults to acquire a global lock when executing C extension code for maximum compatibility (Ruby code OTOH can always run in parallel).
There is a command-line option for that lock and it can be disabled, but then it is disabled for all C extensions.
The important property for TruffleRuby is that the C extension does not need a global lock, i.e., that it synchronizes any mutable state in C that could be accessed by multiple threads, such as global C variables.
I believe many C extensions are already thread-safe, or can easily become thread-safe, because they do not rely on global state and do not share the RData objects between threads.

Ractor also needs a way to mark C extensions, to know if it's OK to use the C extension in multiple Ractors in parallel, and that the C extension will not leak non-shareable objects from one Ractor to another, which would lead to bugs & segfaults.
Otherwise, C extensions could only be used on the main/initial Ractor (or need to acquire a process-global lock whenever executing C extension code and ensure no non-shareable objects leak between Ractors), which would be a very big limitation (almost every non-trivial application depends on a C extension transitively).

In both cases, global state in the C extension needs synchronization.
In the thread-safe case, mutable state in C that could be accessed by multiple Ruby threads needs to be synchronized too (there might be no such state, e.g., if C extension objects are created per Thread).
In the Ractor case, the C extension must never pass an object from a Ractor to another, unless it is a shareable object.

What do you think would be a good way to "mark" C extensions?
Maybe defining a symbol in the C extension, similar to the `Init_foo` we have, like say `foo_is_thread_safe`/`foo_is_ractor_safe`?
A symbol including the C extension name seems best, to avoid any possible confusion when looking it up.

Maybe there are other ways to mark C extensions than defining symbols, that could still be read by the Ruby implementation reliably?

I used the term `C extensions` but of course it would apply to native extensions too (including C++/Rust/...).

cc @ko1



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>