<byteit101[m]>
ran into this annoyingness recently
<headius>
byteit101: reline and new IRB are live on master but I have not checked the status of IRB bugs... usually they are an issue on Windows where terminal handling is atrocious
<headius>
there's likely reline and irb updates that could be applied on master too... and I was hoping to start running tests against reline and irb to try to fill in obvious gaps
<headius>
)
<headius>
the original logic for readline uses the jline library... that may have to remain as a fallback when we don't have access to native functions, so trying to make it work better has value too (and it will remain the primary readline through the rest of 9.3.x
<headius>
hmm looks like loom doesn't solve our thread-local issue... virtual threads still get their own set of thread locals
<headius>
so thread-locals will have to transition into fiber-locals and we need a separate construct for thread-locals across real and virtual
<byteit101[m]>
Oh good. I saw mentions of rb-readline too. is that out?
<headius>
that predates reline and worked pretty well but I think it still needed some terminal control
<headius>
reline is the path forward at this point
<byteit101[m]>
do you know if it has full PTY support?
<headius>
FWIW I did a lot of work last winter to get our io/console library passing all tests so that it can run reline better... I don't remember what rb-readline uses for setting terminal flags
<headius>
reline heavily depends on io/console
<headius>
ours is FFI-based
<byteit101[m]>
ha ha i have a patch for rb-readline iirc
<headius>
it passes all tests under CRuby but fails a couple in JRuby because it depends on pty.rb which requires forking
<headius>
hmm I should have been more involved in loom... what they expose in 19 is pretty opaque
<headius>
Continuation is under the covers but not public... they plumb all of this through executors and expect you to just toss tasks into it that will run with m:n threading
<headius>
my first thought would be that instead of an executor that runs all fibers... we have an executor with one native thread that runs all fibers in a given Ruby thread
<headius>
each thread start would create a new virtual thread executor backed by one native thread
<headius>
the lack of control over which vthread is running might make this tricky to manage
<headius>
hmm
<headius>
if every fiber submitted is initially blocked then it will have to schedule unblocked one... that may be the way to hand-off
<headius>
I want access to these mount/unmount methods in the VirtualThread class though