Memray needs to be thread-safe to run under free-threading

[ZeroIntensity]

Is there an existing proposal for this?

• I have searched the existing proposals

Is your feature request related to a problem?

Memray exposes a programmatic API for profiling, which needs to be thread-safe in order to run under free-threaded builds of Python.

Describe the solution you'd like

I don't think we need to worry about scaling too much. Critical sections should definitely work for Cython code, especially since they now have free-threading support.

For Memray's C++ code, critical sections probably won't work (because a lot of global state isn't owned by objects), so some global PyMutex locks will probably end up being the best choice.

I'll begin working on this sometime soon.

Alternatives you considered

No response

[godlygeek]

Hm, checking this out again, I thought that Tracker.__enter__ and Tracker.__exit__ use the GIL as part of their synchronization, but it looks like that hasn't been true since 29daff6 was landed last year.

Given that, there might not actually be much to do here. Maybe nothing at all, beyond telling Cython that the module is free-threading compatible with the freethreading_compatible directive?

For Memray's C++ code, critical sections probably won't work (because a lot of global state isn't owned by objects), so some global PyMutex locks will probably end up being the best choice.

Memray's C++ code already uses std::mutex whenever it's accessing a shared data structure, and that will work fine for serializing access across threads even in a free threading build.

[ZeroIntensity]

Memray's C++ code already uses std::mutex whenever it's accessing a shared data structure, and that will work fine for serializing access across threads even in a free threading build.

Oh, cool! I'll try setting up 3.13t and 3.14t in CI, then.