Skip to content

Commit 13148f9

Browse files
committed
Update comment that was still referring to a different, less-robust approach that I tried
1 parent b5f9d23 commit 13148f9

File tree

1 file changed

+9
-10
lines changed

1 file changed

+9
-10
lines changed

src/greenlet/greenlet_greenlet.hpp

Lines changed: 9 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -418,16 +418,15 @@ namespace greenlet
418418

419419
#if GREENLET_PY312
420420
// Must be called on 3.12+ before exposing a suspended greenlet's
421-
// frames to user code. This synthesizes a frame object if necessary
422-
// for each interpreter frame on the greenlet's stack, and stitches
423-
// together their f_back pointers so that Python accesses to f_back
424-
// don't need to walk the interpreter frame stack. This is important
425-
// because the interpreter frame stack contains some entries that are
426-
// on the C stack and the interpreter will crash when trying to
427-
// traverse those for a suspended greenlet. The f_back pointer work
428-
// must be undone before resuming the greenlet because the interpreter
429-
// assumes f_back is nullptr for running frames. This is tracked via
430-
// PythonState::frames_were_exposed.
421+
// frames to user code. This rewrites the linked list of interpreter
422+
// frames to skip the ones that are being stored on the C stack (which
423+
// can't be safely accessed while the greenlet is suspended because
424+
// that stack space might be hosting a different greenlet), and
425+
// sets PythonState::frames_were_exposed so we remember to restore
426+
// the original list before resuming the greenlet. The C-stack frames
427+
// are a low-level interpreter implementation detail; while they're
428+
// important to the bytecode eval loop, they're superfluous for
429+
// introspection purposes.
431430
void expose_frames();
432431

433432
// To support code that exposes greenlet frames other than through

0 commit comments

Comments
 (0)