<cremes[m]>
with JRuby and TruffleRuby both sporting native threads and no GIL for a long time, it just doesn't make sense to me to hobble new code under the assumption that there is a GIL like Ruby3 still has
<enebo[m]>
cremes: yeah that is reasonable. why paint yourself into that
<enebo[m]>
cremes: also it never is right to get sucked into that I don't need to worry about concurrency issues even with MRI
<cremes[m]>
yes, no argument from me
<enebo[m]>
I should have probably loaded up rutie and I have not made it to where it is doing actual calls back to MRI but it appears to be built around Value as a concept
<enebo[m]>
A lot of implicit assumptions about MRIs internals but perhaps types from a rust API perspective could have different types impls here. My fear on this is since rutie never considered us we would be making some JNIish layer to reproduce the subset of cext API
<enebo[m]>
Or this project would get more generified (I mean abstractly not rust generic)
<cremes[m]>
aha, so Rutie isn't interfacing to CRuby via fiddle + FFI then?
<cremes[m]>
I didn't realize it was going right into CRuby internals, sigh
<enebo[m]>
having said that most of the things I see would be simple to rewrite through a JNI interface (and Rust does have nice JNI bindings)
<enebo[m]>
I have only been looking at Rust -> CRuby not CRuby -> Rust
<enebo[m]>
It is possible one direction is using fiddle
<enebo[m]>
I see a lot of C calling convention. This is the call Rust from Ruby side where it largely just defines init to call something implemented in Rust
<enebo[m]>
So I don't think so?
<cremes[m]>
hmmm, that would be a bummer
<cremes[m]>
sheesh, it's 2022... why is anyone using CRuby internals directly anymore when FFI has literally existed for 15+ years
<enebo[m]>
yeah
<headius>
cremes: hey ltns
<headius>
enebo: spent some time on fiber raise today and got a few things passing but I'm kinda throwing darts... need to read through these specs more and figure out expected behavior
<headius>
the code in CRuby is deceptively simple because they don't have the same exchange complexities that we do
<headius>
it looks like I need to add an operation to the transfer so it knows how to raise
<enebo[m]>
I will land some newer keywords stuff today
<headius>
CRuby just transfers the exception object it created, so the other side of the transfer must know to raise it
<enebo[m]>
I think we may need to do something a tad less brittle but we can look at it
<headius>
anything's possible
<enebo[m]>
worst case we add one field we can examine per call
<enebo[m]>
right now it is a single field per thread
<enebo[m]>
that is much more brittle because native impls like new need to forward the state