gh-137992: Stop the world when calling PyRefTracer_SetTracer and PyRefTracer_GetTracer #137994
Conversation
| return 0; | ||
| } | ||
|
|
||
| PyRefTracer PyRefTracer_GetTracer(void** data) { | ||
| _Py_AssertHoldsTstate(); | ||
| _PyEval_StopTheWorldAll(&_PyRuntime); |
There was a problem hiding this comment.
Generally the point of stop-the-world is that it functions like an RW lock. Fast, uncontended reads, with a single thread getting exclusive access while writing. Do we write to tracer_data anywhere else?
There was a problem hiding this comment.
It's written by PyRefTracer_SetTracer above
There was a problem hiding this comment.
Right, but then we don't need to stop the world for the reader. I was asking about other writers to see if there was a reason the reader had exclusive access.
There was a problem hiding this comment.
I think you're right, I don't think we need a stop-the-world for PyRefTracer_GetTracer. If we did, we'd also need one for _PyReftracerTrack, which is obviously not reasonable.
| @@ -3286,16 +3286,20 @@ _Py_SetRefcnt(PyObject *ob, Py_ssize_t refcnt) | |||
|
|
|||
| int PyRefTracer_SetTracer(PyRefTracer tracer, void *data) { | |||
| _Py_AssertHoldsTstate(); | |||
| _PyEval_StopTheWorldAll(&_PyRuntime); | |||
| _PyRuntime.ref_tracer.tracer_func = tracer; | |||
There was a problem hiding this comment.
Note that this will still race with isolated subinterpreters on non-FT builds.
…d PyRefTracer_GetTracer
Uh oh!
There was an error while loading. Please reload this page.