gh-111968: Use per-thread freelists for float in free-threading#113886
Conversation
| _PyGC_ClearAllFreeLists(PyInterpreterState *interp) | ||
| { | ||
| _PyTuple_ClearFreeList(interp); | ||
| _PyFloat_ClearFreeList(interp); |
There was a problem hiding this comment.
Integrated with _Py_ClearFreeLists
| _PyGC_ClearAllFreeLists(PyInterpreterState *interp) | ||
| { | ||
| _PyTuple_ClearFreeList(interp); | ||
| _PyFloat_ClearFreeList(interp); |
There was a problem hiding this comment.
Integrated with _Py_ClearFreeLists
| }; | ||
|
|
||
| typedef struct _Py_freelist_state { | ||
| struct _Py_float_state float_state; |
There was a problem hiding this comment.
Why not use the same naming scheme? The list freelist state member is named list.
There was a problem hiding this comment.
Because float is reserved name?
There was a problem hiding this comment.
If we decide to change the naming schme, list should be changed. WDYT?
There was a problem hiding this comment.
I think that the naming of a struct and its members is an important part of API design. Having a consistent scheme makes it easier to read and review code. I would suggest use a naming scheme for the freelist struct and its members. Up to you :)
There was a problem hiding this comment.
Totally agree, I will create a seperate PR :)
| } | ||
| state->free_list = NULL; | ||
| state->numfree = 0; | ||
| if (is_finalization) { |
There was a problem hiding this comment.
Previously, we only set num_free to -1 during finalization in debug builds. With this change, we set it in non-debug builds too. I think that's fine (and simpler), but we should better handle the -1 case in PyFloat_ExactDealloc in case assertions are not enabled.
I'd suggest adding changing the condition in PyFloat_ExactDealloc to something like if (state->num_free >= PyFloat_MAXFREELIST || state->num_free < 0) so that num_free=-1 disables the free-list.
3 participants
--disable-gilbuilds #111968