No reason it can't be added in the future.
This could, of course, expose a different C API that allows for thread safe extensions, but I think the original comment is complaining about lack of compatibility with all of the important gems that depend on the existing MRI C API.
This has always been an issue that held back JRuby.
Plenty of talks done on this subject by Charles Nutter.
It also lacks compatibility with a lot of important C gems (not only or even predominantly because of the lack of a GIL, of course), which I’m pointing out has always impacted its adoption.
TruffleRuby supports C extensions, and has no GIL for Ruby code.
Assuming MRB_API thread-safe-able. mruby is not thread safe at all, being a single-threaded script runner.
My expectation is that MRB_API can be implemented in a thread-safe way. The API manipulates the interpreter state (in the case of mruby, an `mrb_state`). The interpreter state itself and the implementation of the API can be thread safe or they can not be.
I don't think mruby even assumes the presence of threads on target systems, so it is completely reasonable that the implementation is not thread safe.
However, it may be possible to use `rubysys` in rutie as a base for an MRI compatible API: https://github.com/artichoke/artichoke/issues/88
I think one difficulty there is some global state in C extensions might expect to be truly process-global.
Also, how would you isolate global variables in the C extension? If the C extension is a dynamic library, it's typically only loaded once per process. Maybe something like dlmopen() to load multiple copies of a native library would help, but it's not portable.
IMHO the only way to do it is to add incremental parallelism which leaves the GIL in place. Racket has already shown a solid path here.
Guilds would have a major performance problem: can't allocate objects without GIL. It's also a tricky mental model and requires invasive changes to existing Ruby code to handle frozen objects.
Places don't share a heap so they don't need the GIL to allocate objects and have independent GC rather than global GC. It's a model which fits better with existing Ruby code. The GVL can be relaxed while executing Ruby and grabbed by native methods.
WDYT?
Why not? It'd be possible to have TLABs, isn't it? But yes, GC would still be for all Guilds at once.
Racket places don't allow to share objects, only arrays of primitive types, which seems very restrictive. And Racket futures are even more restricted.
I'm not sure about Guilds since it's not there yet, but it already sounds closer to Ruby multithreading and more flexible to me from an usage point of view.
Places are deliberately shared-nothing to reduce the implementation complexity and provide a simple model to the user. Process oriented code can be easily ported.
Porting something like a Sidekiq based worker using ActiveRecord to work inside a Guild where all access to shared objects needs to be frozen would be a nightmare.
With Racket Places you can share more complex types but it needs to be done via FFI. It doesn't prevent you from implementing a sharable connection pool or anything.