ruby.git/lib/irb/debug, branch v3_3_11 The Ruby Programming Language [ruby/irb] Avoid locking the debug UI to a single thread 2023-10-11T14:16:39+00:00 Stan Lo stan001212@gmail.com 2023-10-11T14:16:32+00:00 cc311e1c4599200dd7437cd578e61c83067e555c (https://github.com/ruby/irb/pull/725) Since `debug` stores and updates the target thread via its Session's `@tc` variable, we don't need to and shouldn't lock the UI to the thread that activates the integration. https://github.com/ruby/irb/commit/202efdbf0c 
(https://github.com/ruby/irb/pull/725)

Since `debug` stores and updates the target thread via its Session's
`@tc` variable, we don't need to and shouldn't lock the UI to the thread
that activates the integration.

https://github.com/ruby/irb/commit/202efdbf0c
[ruby/irb] Support seamless integration with ruby/debug 2023-08-13T18:30:34+00:00 Stan Lo stan001212@gmail.com 2023-08-13T18:30:30+00:00 7f8f62c93bf3d11a0321fa91823065a2ff36f6d0 (https://github.com/ruby/irb/pull/575) * Support native integration with ruby/debug * Prevent using multi-irb and activating debugger at the same time Multi-irb makes a few assumptions: - IRB will manage all threads that host sub-irb sessions - All IRB sessions will be run on the threads created by IRB itself However, when using the debugger these assumptions are broken: - `debug` will freeze ALL threads when it suspends the session (e.g. when hitting a breakpoint, or performing step-debugging). - Since the irb-debug integration runs IRB as the debugger's interface, it will be run on the debugger's thread, which is not managed by IRB. So we should prevent the 2 features from being used at the same time. To do that, we check if the other feature is already activated when executing the commands that would activate the other feature. https://github.com/ruby/irb/commit/d8fb3246be 
(https://github.com/ruby/irb/pull/575)

* Support native integration with ruby/debug

* Prevent using multi-irb and activating debugger at the same time

Multi-irb makes a few assumptions:

- IRB will manage all threads that host sub-irb sessions
- All IRB sessions will be run on the threads created by IRB itself

However, when using the debugger these assumptions are broken:

- `debug` will freeze ALL threads when it suspends the session (e.g. when
  hitting a breakpoint, or performing step-debugging).
- Since the irb-debug integration runs IRB as the debugger's interface,
  it will be run on the debugger's thread, which is not managed by IRB.

So we should prevent the 2 features from being used at the same time.
To do that, we check if the other feature is already activated when
executing the commands that would activate the other feature.

https://github.com/ruby/irb/commit/d8fb3246be