Issue #15912 has been updated by deivid (David Rodr=EDguez).


The idea is to avoid recursive calls to the same event, but allow other kin=
d of reentrancy. With a real script:

```ruby
line_handler1 =3D TracePoint.trace(:line) do |tp|                     # L1
  puts "Handler 1 starts (triggered from #{tp.path}:#{tp.lineno})"  # L2
  puts "Handler 1 ends (triggered from #{tp.path}:#{tp.lineno})"    # L3
end                                                                 # L4
                                                                    # L5  =

line_handler2 =3D TracePoint.trace(:line) do |tp|                     # L6 =

  puts "Handler 2 starts (triggered from #{tp.path}:#{tp.lineno})"  # L7
  puts "Handler 2 ends (triggered from #{tp.path}:#{tp.lineno})"    # L8
end                                                                 # L9
                                                                    # L10
puts "I'm a line"                                                   # L11
```

Current output is

> Handler 1 starts (triggered by line tp.rb:6)
> Handler 1 ends (triggered by line tp.rb:6)
> Handler 2 starts (triggered by line tp.rb:11)
> Handler 2 ends (triggered by line tp.rb:11)
> Handler 1 starts (triggered by line tp.rb:11)
> Handler 1 ends (triggered by line tp.rb:11)
> I'm a line

Proposed output would be

> Handler 1 starts (triggered by line tp.rb:6)
> Handler 1 ends (triggered by line tp.rb:6)
> Handler 2 starts (triggered by line tp:11)
> Handler 1 starts (triggered by line tp:7)
> Handler 1 ends (triggered by line tp:7)
> Handler 2 ends (triggered by line tp:11)
> Handler 1 starts (triggered by line tp:8)
> Handler 1 ends (triggered by line tp:8)
> I'm a line


By maybe the explicit solution you propose is better: allow every event to =
be executed, also for code inside handlers, and let the user be in control =
of avoiding potential infinite loops.

----------------------------------------
Feature #15912: Allow some reentrancy during TracePoint events
https://bugs.ruby-lang.org/issues/15912#change-80751

* Author: deivid (David Rodr=EDguez)
* Status: Assigned
* Priority: Normal
* Assignee: ko1 (Koichi Sasada)
* Target version: =

----------------------------------------
I got a report in byebug about byebug being incompatible with zeitwerk. Thi=
s one: https://github.com/deivid-rodriguez/byebug/issues/564. This is a pro=
blem because zeitwerk is the default Rails code loader, and byebug is the d=
efault Rails debugger.

Both of these tools rely on the TracePoint API:

* Byebug uses a bunch of TracePoint events to stop execution at certain poi=
nts in your program.
* Zeitwek uses `:class` events to be able to resolve some circular edge cas=
es.

I investigated the problem and I think the issue is that while stopped at t=
he byebug prompt, we're actually in the middle of processing a TracePoint e=
vent. That means that further TracePoint events triggered at the byebug's p=
rompt will be ignored, because otherwise we could get into an infinite loop=
 where the handling of events would trigger more events that trigger themse=
lves the execution of handlers again.

I understand why the TracePoint API does this, but if we could allow some l=
evel of reentrancy here, we could probably make these tools play nice toget=
her. I figure if we kept a stack of TracePoint event handlers being run, an=
d check that the current event type is not already in the stack, we would a=
llow :class events to be triggered from :line events, and I think that woul=
d allow Zeitwerk to work within byebug.

What do you think about this, @ko1?



-- =

https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=3Dunsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>