I think this makes sense, but it'd be helpful if@DinoV and@mpage can also take a look at it.

From our discussion, locking code objects forde-instrumentation after calling tools isn't sufficient because other threads may be in the middle of running those code objects. We need a stop the world pause there, given the current design.

I think this makes sense, but to make sure I understand correctly, the issue here is that without this change other threads may be using the tools concurrently with their removal. Is that right?

the issue here is that without this change other threads may be using the tools concurrently with their removal. Is that right?

The issue is that while the tools are removed which involves modifying thread local bytecode inMODIFY_BYTECODE for all threads, other threads can be concurrently running the bytecode which causes data race.

The issue is that while the tools are removed which involves modifying thread local bytecode in MODIFY_BYTECODE for all threads, other threads can be concurrently running the bytecode which causes data race.

Ah, ok. We intended to use atomics to avoid data races on the bytecode; looks we missed some places that should use them. Stop-the-world certainly fixes them and is easier to reason about, but it does come with a performance cost. I think that tradeoff is probably acceptable for now and we can revisit later if need be.

I think we should include a NEWS entry and request a backport to 3.14

Thanks@kumaraditya303 for the PR 🌮🎉.. I'm working now to backport this PR to: 3.14.
🐍🍒⛏🤖

GH-137082 is a backport of this pull request to the3.14 branch.