Ruby Issue Tracking System: Issueshttps://bugs.ruby-lang.org/https://bugs.ruby-lang.org/favicon.ico?17113305112023-05-01T23:29:56ZRuby Issue Tracking System
Redmine Ruby master - Feature #19627 (Closed): Ensure the VM is alive before accessing objspace in C APIhttps://bugs.ruby-lang.org/issues/196272023-05-01T23:29:56Zianks (Ian Ker-Seymer)
<p>Currently, there is no supported way to check if the Ruby VM has been shut down. There are a couple of workarounds that I know of:</p>
<ol>
<li>Setup an exit handler which sets a global variable (like I did in <a href="https://github.com/tmm1/stackprof/pull/200" class="external">https://github.com/tmm1/stackprof/pull/200</a>).</li>
<li>In Ruby 2.4 thru 3.2, you could check the hidden <code>ruby_vm_global_ptr != NULL</code>.</li>
</ol>
<p>For my use, in rb-sys there is a feature to automatically report Rust memory allocations via <code>rb_gc_adjust_memory_usage</code>. However, there is a bug that can cause processes to deadlock and/or segfault if a Rust destructor gets called after the VM quits (which can happen in Rust background threads). Currently, I don’t think there’s a way to safely make this feature work. (<a href="https://github.com/oxidize-rb/rb-sys/pull/205" class="external">https://github.com/oxidize-rb/rb-sys/pull/205</a>)</p>
<p>It would be nice to have an official way to know if the Ruby VM is available, basically just a <code>ruby_current_vm_ptr != null</code>. Thoughts?</p> Ruby master - Feature #15759 (Third Party's Issue): Support Rust/Cargo in Gem::Ext::Builderhttps://bugs.ruby-lang.org/issues/157592019-04-10T02:31:06Zianks (Ian Ker-Seymer)
<p>Over the past few years, Rust has proven to be an incredibly stable and accessible option for those wishing to write native extensions for Ruby. Rust is particularly well-suited for Ruby for a few reasons:</p>
<ol>
<li>Integration is straight-forward, since it is easy to expose a C compatible API using <code>extern C</code>
</li>
<li>Rust is a bit more high-level, and approachable for Ruby developers since it prevents many of the classic C footguns (use-after-free, etc)</li>
<li>The landing page can explain the benefits better than me. Check out <a href="https://www.rust-lang.org/" class="external">https://www.rust-lang.org/</a> if you aren't fully convinced.</li>
</ol>
<p>One of the biggest pain points of creating a Gem with a Rust extension is integrating with Gem::Ext::Builder. There are currently a couple of solutions, and the rely on the <code>RakeBulider</code> interface. I have personally used <a href="https://github.com/malept/thermite" class="external">https://github.com/malept/thermite</a>, which is a very good solution, but still requires and external dependency and does not integrate as well as native builders at the moment.<br>
<code>Currently, Gem::Ext::Builder supports four builder types:</code>ExtConfBuilder<code>, </code>ConfigureBuilder<code>, </code>RakeBuilder<code>, and </code>CmakeBuilder<code>. I propose we add a new builder, </code>CargoBuilder<code>, which will detect a </code>cargo.toml` file and build the gem from that. This ease the burden of developing and publishing Rust extensions for Ruby users.</p>
<a name="Potential-Problems"></a>
<h3 >Potential Problems<a href="#Potential-Problems" class="wiki-anchor">¶</a></h3>
<ol>
<li>
<p>If the user does not have <code>cargo</code> installed, building the extension will not work.<br>
This is an issue, but is also an issue for the CmakeBuilder. One way to mitigate this issue would be to make it easier to build static binaries for Rust extensions.</p>
</li>
<li>
<p>The lack of a standard ruby interface for Rust extensions might cause pain for developers.<br>
Currently, many folks use <a href="https://github.com/steveklabnik/ruby-sys" class="external">https://github.com/steveklabnik/ruby-sys</a> to interface with the C ruby API. It might make sense to make this "officially" supported at some point, but I don't think it has to be done immediately.</p>
</li>
</ol>
<p>Please let me know your thoughts. I would be very excited to see Ruby take this step. I don't think I know enough about the Ruby extension building process or the Rust compilation process to actually implement this, so hopefully we could find a volunteer to step up. Thanks for reading :)</p>