Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

_PyWeakref_ClearRef and _PyWeakref_ClearWeakRefsExceptCallbacks should be exposed in 3.13 #118789

Closed
colesbury opened this issue May 8, 2024 · 0 comments
Closed

_PyWeakref_ClearRef and _PyWeakref_ClearWeakRefsExceptCallbacks should be exposed in 3.13 #118789

colesbury opened this issue May 8, 2024 · 0 comments
Labels
topic-C-API topic-free-threading

Comments

@colesbury
Copy link
Contributor

colesbury commented May 8, 2024 •
edited by bedevere-app bot
Loading

_PyWeakref_ClearRef was previously exposed in the public C-API. In 3.13, it was moved to pycore_weakref.h and the symbol is not exposed (i.e., it's extern void instead of PyAPI_FUNC(void).

_PyWeakref_ClearRef is used to clear a single weakref without calling its callback. _PyWeakref_ClearWeakRefsExceptCallbacks is the thread-safe version. If people are using _PyWeakref_ClearRef, we'd rather they use _PyWeakref_ClearWeakRefsExceptCallbacks so that the code is thread-safe in the free-threading build.

One use case is to clear newly added weakrefs after you've called a finalizer, in case your C type does not delegate to subtype_dealloc.

Uses:

At a minimum, we should add PyAPI_FUNC to _PyWeakref_ClearRef and _PyWeakref_ClearWeakRefsExceptCallbacks and consider making _PyWeakref_ClearWeakRefsExceptCallbacks part of the public C API.

Linked PRs
colesbury added a commit to colesbury/cpython that referenced this issue May 8, 2024
@colesbury
pythongh-118789: Restore hidden _PyWeakref_ClearRef
0d5ae9b 
_PyWeakref_ClearRef was previously exposed in the public C-API, although
it begins with an underscore and is not documented. It's used by a few
C-API extensions. There is currently no alternative public API that can
replace its use.

_PyWeakref_ClearWeakRefsExceptCallbacks is the only thread-safe way to
use _PyWeakref_ClearRef in the free-threaded build. This exposes the C
symbol, but does not make the API public.
@bedevere-app bedevere-app bot mentioned this issue May 8, 2024
Merged
colesbury added a commit to colesbury/cpython that referenced this issue May 8, 2024
@colesbury
pythongh-118789: Add PyUnstable_Weakref_ClearWeakRefsExceptCallbacks
f1fc2bc 
This exposes `_PyWeakref_ClearWeakRefsExceptCallbacks` as an unstable
C-API function to provide a thread-safe mechanism for clearing weakrefs
without executing callbacks.

Some C-API extensions need to clear weakrefs without calling callbacks,
such as after running finalizers like we do in subtype_dealloc.
Previously they could use `_PyWeakref_ClearRef` on each weakref, but
that's not thread-safe in the free-threaded build.
@bedevere-app bedevere-app bot mentioned this issue May 8, 2024
Merged
encukou pushed a commit that referenced this issue May 10, 2024
@colesbury
gh-118789: Restore hidden _PyWeakref_ClearRef (#118797)
db5af7d 
_PyWeakref_ClearRef was previously exposed in the public C-API, although
it begins with an underscore and is not documented. It's used by a few
C-API extensions. There is currently no alternative public API that can
replace its use.

_PyWeakref_ClearWeakRefsExceptCallbacks is the only thread-safe way to
use _PyWeakref_ClearRef in the free-threaded build. This exposes the C
symbol, but does not make the API public.
miss-islington pushed a commit to miss-islington/cpython that referenced this issue May 10, 2024
@colesbury @miss-islington
pythongh-118789: Restore hidden _PyWeakref_ClearRef (pythonGH-118797)
c291cf8 
_PyWeakref_ClearRef was previously exposed in the public C-API, although
it begins with an underscore and is not documented. It's used by a few
C-API extensions. There is currently no alternative public API that can
replace its use.

_PyWeakref_ClearWeakRefsExceptCallbacks is the only thread-safe way to
use _PyWeakref_ClearRef in the free-threaded build. This exposes the C
symbol, but does not make the API public.
(cherry picked from commit db5af7d)

Co-authored-by: Sam Gross <[email protected]>
@bedevere-app bedevere-app bot mentioned this issue May 10, 2024
Merged
encukou pushed a commit that referenced this issue May 10, 2024
@miss-islington @colesbury
[3.13] gh-118789: Restore hidden _PyWeakref_ClearRef (GH-118797) (G…
bb5bf24 
…H-118903)

gh-118789: Restore hidden `_PyWeakref_ClearRef` (GH-118797)

_PyWeakref_ClearRef was previously exposed in the public C-API, although
it begins with an underscore and is not documented. It's used by a few
C-API extensions. There is currently no alternative public API that can
replace its use.

_PyWeakref_ClearWeakRefsExceptCallbacks is the only thread-safe way to
use _PyWeakref_ClearRef in the free-threaded build. This exposes the C
symbol, but does not make the API public.
(cherry picked from commit db5af7d)

Co-authored-by: Sam Gross <[email protected]>
@JelleZijlstra JelleZijlstra mentioned this issue May 28, 2024
Closed
colesbury added a commit to colesbury/cpython that referenced this issue Jun 17, 2024
@colesbury
Merge branch 'main' into pythongh-118789-PyUnstable_Weakref_ClearWeak…
29582a9 
…RefsExceptCallbacks
colesbury added a commit that referenced this issue Jun 18, 2024
@colesbury @encukou
gh-118789: Add PyUnstable_Object_ClearWeakRefsNoCallbacks (#118807)
e8752d7 
This exposes `PyUnstable_Object_ClearWeakRefsNoCallbacks` as an unstable
C-API function to provide a thread-safe mechanism for clearing weakrefs
without executing callbacks.

Some C-API extensions need to clear weakrefs without calling callbacks,
such as after running finalizers like we do in subtype_dealloc.
Previously they could use `_PyWeakref_ClearRef` on each weakref, but
that's not thread-safe in the free-threaded build.

Co-authored-by: Petr Viktorin <[email protected]>
miss-islington pushed a commit to miss-islington/cpython that referenced this issue Jun 18, 2024
@colesbury @encukou @miss-islington
pythongh-118789: Add PyUnstable_Object_ClearWeakRefsNoCallbacks (py…
1479692 
…thonGH-118807)

This exposes `PyUnstable_Object_ClearWeakRefsNoCallbacks` as an unstable
C-API function to provide a thread-safe mechanism for clearing weakrefs
without executing callbacks.

Some C-API extensions need to clear weakrefs without calling callbacks,
such as after running finalizers like we do in subtype_dealloc.
Previously they could use `_PyWeakref_ClearRef` on each weakref, but
that's not thread-safe in the free-threaded build.

(cherry picked from commit e8752d7)

Co-authored-by: Sam Gross <[email protected]>
Co-authored-by: Petr Viktorin <[email protected]>
@bedevere-app bedevere-app bot mentioned this issue Jun 18, 2024
Merged
colesbury added a commit that referenced this issue Jun 18, 2024
@miss-islington @colesbury @encukou
[3.13] gh-118789: Add PyUnstable_Object_ClearWeakRefsNoCallbacks (G…
1ce5984 
…H-118807) (#120695)

This exposes `PyUnstable_Object_ClearWeakRefsNoCallbacks` as an unstable
C-API function to provide a thread-safe mechanism for clearing weakrefs
without executing callbacks.

Some C-API extensions need to clear weakrefs without calling callbacks,
such as after running finalizers like we do in subtype_dealloc.
Previously they could use `_PyWeakref_ClearRef` on each weakref, but
that's not thread-safe in the free-threaded build.

(cherry picked from commit e8752d7)

Co-authored-by: Sam Gross <[email protected]>
Co-authored-by: Petr Viktorin <[email protected]>
picnixz pushed a commit to picnixz/cpython that referenced this issue Jun 19, 2024
@colesbury @encukou @picnixz
pythongh-118789: Add PyUnstable_Object_ClearWeakRefsNoCallbacks (py…
67b9e2c 
…thon#118807)

This exposes `PyUnstable_Object_ClearWeakRefsNoCallbacks` as an unstable
C-API function to provide a thread-safe mechanism for clearing weakrefs
without executing callbacks.

Some C-API extensions need to clear weakrefs without calling callbacks,
such as after running finalizers like we do in subtype_dealloc.
Previously they could use `_PyWeakref_ClearRef` on each weakref, but
that's not thread-safe in the free-threaded build.

Co-authored-by: Petr Viktorin <[email protected]>
mrahtz pushed a commit to mrahtz/cpython that referenced this issue Jun 30, 2024
@colesbury @encukou @mrahtz
pythongh-118789: Add PyUnstable_Object_ClearWeakRefsNoCallbacks (py…
50f7f2f 
…thon#118807)

This exposes `PyUnstable_Object_ClearWeakRefsNoCallbacks` as an unstable
C-API function to provide a thread-safe mechanism for clearing weakrefs
without executing callbacks.

Some C-API extensions need to clear weakrefs without calling callbacks,
such as after running finalizers like we do in subtype_dealloc.
Previously they could use `_PyWeakref_ClearRef` on each weakref, but
that's not thread-safe in the free-threaded build.

Co-authored-by: Petr Viktorin <[email protected]>
noahbkim pushed a commit to hudson-trading/cpython that referenced this issue Jul 11, 2024
@colesbury @encukou @noahbkim
pythongh-118789: Add PyUnstable_Object_ClearWeakRefsNoCallbacks (py…
6c5a398 
…thon#118807)

This exposes `PyUnstable_Object_ClearWeakRefsNoCallbacks` as an unstable
C-API function to provide a thread-safe mechanism for clearing weakrefs
without executing callbacks.

Some C-API extensions need to clear weakrefs without calling callbacks,
such as after running finalizers like we do in subtype_dealloc.
Previously they could use `_PyWeakref_ClearRef` on each weakref, but
that's not thread-safe in the free-threaded build.

Co-authored-by: Petr Viktorin <[email protected]>
estyxx pushed a commit to estyxx/cpython that referenced this issue Jul 17, 2024
@colesbury @encukou @estyxx
pythongh-118789: Add PyUnstable_Object_ClearWeakRefsNoCallbacks (py…
a3b9570 
…thon#118807)

This exposes `PyUnstable_Object_ClearWeakRefsNoCallbacks` as an unstable
C-API function to provide a thread-safe mechanism for clearing weakrefs
without executing callbacks.

Some C-API extensions need to clear weakrefs without calling callbacks,
such as after running finalizers like we do in subtype_dealloc.
Previously they could use `_PyWeakref_ClearRef` on each weakref, but
that's not thread-safe in the free-threaded build.

Co-authored-by: Petr Viktorin <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
topic-C-API topic-free-threading
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@colesbury