binding.irb and Async::Task

[olivierlacan]

I'm curious how the debugging story when a binding.irb call stops execution of not one but several parallel async tasks could be handled in a somewhat user friendly way.

Currently you end up streaming IRB input to all the active tasks for a single session which means you have to type each letter twice for example. It might be very non-obvious to some users.

Could we detect that a debug session is active and help users at least notice they're sending input to two different Tasks? Or would it be possible to somehow split the binding.irb sessions tmux style and switch between them?

Very much spitballing here and this might be a concerted convo with @st0012, @k0kubun, or @aycabta maybe since I'm guessing they might have way more experience and ideas for IRB in that domain?

[trevorturk]

See also ruby/debug#486

[ioquatix]

binding.irb uses normal blocking IO which is transparently non-blocking when run inside Async{}, so binding.irb does not block the reactor.

For fun you can do this:

alias arb "ruby -rasync -e 'Async{|task| binding.irb; task.stop}'"

e.g.

> alias arb "ruby -rasync -e 'Async{|task| binding.irb; task.stop}'"
> arb
irb(main):001:0> Async{sleep 1; puts "done"}
=> #<Async::Task:0x000000000000a5a0 /home/samuel/.gem/ruby/3.2.1/gems/async-2.5.0/lib/async/scheduler.rb:123:in `transfer'>
irb(main):002:0> done

To your specific question, if you start two binding.irb sessions, is the same if you do it in two threads, etc. You will experience odd interleaved input/output.

In order to "stop the world" w.r.t. multiple binding.irb sessions, you'd need to use a Thread::Mutex or similar synchronisation primative. It would probably make sense for this problem to be solved in irb itself. i.e. binding.irb should have a top level instance of the IRB state, which has a mutex attached to it.