You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
design-docs/design-001.md: Fix design of MonitoringEvents
The values of the events should come from sys.monitoring and not be set in the Rust code, because we risk inconsistencies this way
Signed-off-by: Tzanko Matev <[email protected]>
design-docs/design-001.md: Fix event callback types and get rid of PyFrameObject
PyFrameObject is not part of sys.monitroing API
Signed-off-by: Tzanko Matev <[email protected]>
design-docs/design-001.md: CodeObject access
Since PyO3 doesn't provide access to PyCodeObject internals we need an alternative way to access them
Signed-off-by: Tzanko Matev <[email protected]>
design-docs/design-001.md: We'll ignore BRANCH events initially
Signed-off-by: Tzanko Matev <[email protected]>
@@ -45,108 +73,165 @@ The tracer collects `sys.monitoring` events, converts them to `runtime_tracing`
45
73
```
46
74
47
75
### Frame and Thread Tracking
48
-
- Maintain a per-thread stack of frame identifiers to correlate `CALL`, `PY_START`, and returns.
76
+
- Maintain a per-thread stack of activation identifiers to correlate `CALL`, `PY_START`, yields, and returns. Since `sys.monitoring` callbacks provide `CodeType` and offsets (not frames), we rely on the nesting order of events to track activations.
// Hold a GIL-independent handle to the CodeType object.
87
+
// Access required attributes via PyO3 attribute lookup (getattr) under the GIL.
88
+
pubcode:PyObject,
89
+
}
58
90
```
59
-
- Record thread start/end events when a new thread registers callbacks.
91
+
- Record thread start/end events when a thread first emits a monitoring event and when it finishes.
60
92
```rs
61
93
pubfnon_thread_start(thread_id:u64);
62
94
pubfnon_thread_stop(thread_id:u64);
63
95
```
64
96
97
+
### Code Object Access Strategy (no reliance on PyCodeObject internals)
98
+
- Rationale: PyO3 exposes `ffi::PyCodeObject` as an opaque type. Instead of touching its unstable layout, treat code objects as generic Python objects and access only stable Python-level attributes via PyO3's `getattr` on `&PyAny`.
99
+
```rs
100
+
usepyo3::{prelude::*, types::PyAny};
101
+
102
+
#[derive(Clone)]
103
+
pubstructCodeInfo {
104
+
pubfilename:String,
105
+
pubqualname:String,
106
+
pubfirstlineno:u32,
107
+
pubflags:u32,
108
+
}
109
+
110
+
/// Stable identity for a code object during its lifetime.
111
+
/// Uses the object's address while GIL-held; equivalent to Python's id(code).
- Event handler inputs use `PyObject` for the `code` parameter. Borrow to `&PyAny` with `let code = code.bind(py);` when needed, then consult `CodeRegistry`.
147
+
- For line numbers: rely on the `LINE` event’s provided `line_number`. If instruction offsets need mapping, call `code.getattr("co_lines")()?.call0()?` and iterate lazily; avoid caching unless necessary.
148
+
65
149
## Event Handling
66
150
67
151
Each bullet below represents a low-level operation translating a single `sys.monitoring` event into the `runtime_tracing` stream.
68
152
69
153
### Control Flow
70
-
-**PY_START** – Create a `Function` event for the code object and push a new frame ID onto the thread's stack.
154
+
-**PY_START** – Create a `Function` event for the code object and push a new activation ID onto the thread's stack.
-**CALL** – Record a `Call` event, capturing argument values and the callee's `Function` ID.
189
+
-**CALL** – Record a `Call` event, capturing the `callable` and the first argument if available (`arg0` as provided by `sys.monitoring`), and associate a new activation.
_Note_: Current runtime_tracing doesn't support branching events, but instead relies on AST tree-sitter analysis. So for the initial version we will ignore them and can add support after modifications to the tracing format.
125
210
126
211
### Exception Lifecycle
127
212
-**RAISE** – Emit an `Event` containing exception type and message when raised.
-**C_RETURN** – On returning from a C function, emit a `Return` event tagged as foreign and include result summary.
222
+
-**C_RETURN** – On returning from a C function, emit a `Return` event tagged as foreign. Note: `sys.monitoring` does not provide the result object for `C_RETURN`.
-**C_RAISE** – When a C function raises, record an `Event`with the exception info and current frame ID.
226
+
-**C_RAISE** – When a C function raises, record an `Event`that a C-level callable raised. Note: `sys.monitoring` does not pass the exception object for `C_RAISE`.
0 commit comments