Add safe context watcher API - #6227
Conversation
| /// storage. State can still be shared through safe static synchronization primitives. | ||
| /// | ||
| /// Panics and returned [`PyErr`][crate::PyErr] values are reported as unraisable exceptions and | ||
| /// never unwind across the C boundary. |
There was a problem hiding this comment.
Should we mention this as well?
/// # Thread Safety
///
/// On GIL-enabled builds, callbacks are invoked synchronously. On free-threaded
/// builds (when this API is available), callbacks may be invoked concurrently.
/// Ensure your callback is thread-safe if needed.
There was a problem hiding this comment.
That's true, It should definitely be mentioned if we enable the API on free threaded builds.
The problem is that PyContext_AddWatcher and PyContext_ClearWatcher while available on free threaded are not callable concurrently and require external synchronization, which is not something we can guarantee from an extension.
I was thinking of making this API only available on GIL-enabled builds for this reason.
There was a problem hiding this comment.
I think we can should requireSend + Sync + 'static on the provided closure.
There was a problem hiding this comment.
The API in this PR accepts a function path, which is coerced to a function pointer. Function pointers carry no captured state and are already Send + Sync + 'static, so there is nothing additional to enforce.
CPython’s watcher API does not expose a user-data pointer where we could store a closure, which is why I did not try to implement a closure registration api.
eb0dff3 to
66ad857
Compare
7259b06 to
69b141c
Compare
|
LGTM, but im not a maintainer |
|
Still, thank you for taking a look. |
Adds
PyContextand safe context-watcher bindings for GIL-enabled CPython 3.14:Tested with unit tests, doctests, and Clippy on Python 3.14.