ruby-core@ruby-lang.org archive (unofficial mirror)
 help / color / mirror / Atom feed
From: ko1@atdot.net
To: ruby-core@ruby-lang.org
Subject: [ruby-core:94194] [Ruby master Feature#15912] Allow some reentrancy during TracePoint events
Date: Thu, 08 Aug 2019 05:50:26 +0000 (UTC)	[thread overview]
Message-ID: <redmine.journal-80488.20190808055026.a89946075edcd97f@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-15912.20190611132542@ruby-lang.org

Issue #15912 has been updated by ko1 (Koichi Sasada).


In this case, your solution (allow fire different type of trace) because the problematic case `:line` event and `:class` event are different.
However, maybe it is accidentally. Someone can use `:line` event as usual.

`reopen` will allow re-occurrence explicitly by TracePoint users (like byebug), I think.
What do you think about it?

To introduce `#reopen`, we need to consider about:
* name (`reopen`? `allow`? `unmask` like signal mask idiom?).
* do we need to pass allowing events? (e.g.: all events except `:line` event are allowed)


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

* Author: deivid (David Rodríguez)
* Status: Assigned
* Priority: Normal
* Assignee: ko1 (Koichi Sasada)
* Target version: 
----------------------------------------
I got a report in byebug about byebug being incompatible with zeitwerk. This one: https://github.com/deivid-rodriguez/byebug/issues/564. This is a problem because zeitwerk is the default Rails code loader, and byebug is the default Rails debugger.

Both of these tools rely on the TracePoint API:

* Byebug uses a bunch of TracePoint events to stop execution at certain points in your program.
* Zeitwek uses `:class` events to be able to resolve some circular edge cases.

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

I understand why the TracePoint API does this, but if we could allow some level of reentrancy here, we could probably make these tools play nice together. I figure if we kept a stack of TracePoint event handlers being run, and check that the current event type is not already in the stack, we would allow :class events to be triggered from :line events, and I think that would 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=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>

  parent reply	other threads:[~2019-08-08  5:50 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <redmine.issue-15912.20190611132542@ruby-lang.org>
2019-06-11 13:25 ` [ruby-core:93043] [Ruby trunk Bug#15912] Allow some reentrancy during TracePoint events deivid.rodriguez
2019-07-29  8:04 ` [ruby-core:93984] [Ruby master Feature#15912] " ko1
2019-07-31 10:51 ` [ruby-core:94071] " deivid.rodriguez
2019-08-08  5:50 ` ko1 [this message]
2019-08-10 15:54 ` [ruby-core:94251] " deivid.rodriguez
2019-08-13  8:14 ` [ruby-core:94318] " ko1
2019-08-13 13:21 ` [ruby-core:94324] " deivid.rodriguez
2019-08-14  6:07 ` [ruby-core:94339] " ko1
2019-08-14 10:36 ` [ruby-core:94348] " deivid.rodriguez
2019-10-03 15:32 ` [ruby-core:95199] " deivid.rodriguez

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.ruby-lang.org/en/community/mailing-lists/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=redmine.journal-80488.20190808055026.a89946075edcd97f@ruby-lang.org \
    --to=ruby-core@ruby-lang.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).