-
-
Notifications
You must be signed in to change notification settings - Fork 31.5k
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.
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
bpo-25658: Implement PEP 539 for Thread Specific Storage (TSS) API #1362
Conversation
@ma8ma, thanks for your PR! By analyzing the history of the files in this pull request, we identified @mhammond, @serhiy-storchaka and @loewis to be potential reviewers. |
See PEP 539 for details. highlights of changes: - Add Thread Specific Storage (TSS) API - Add test for transitions of the thread key state. - Mark deprecation to Thread Local Storage (TLS) API - Replace codes that used TLS API with TSS API
Uh are you rebasing? I made that mistake before. The latest dev guide says to not rebase but include all commits which would then be merged as a single commit. |
@AraHaan Yes, PR is single commit. I confirmed AppVeyor build failed, and retried push in a minute. But it has failed again, I need help for Windows platform... |
It seems to be something with the solution or project settings or even AppVeyor's setting. Will investigate more when I can use the internet on my Inspiron 1545 that has Windows 7 Ultimate SP1 x64 and VS2015 installed. It seems that in the project settings is set to use the Windows sdk for 8.1 instead of for 10. Also when targeting for 10.0 I recommend staticallylinking the ucrt for the versions of Windows that can't install it (Vista). Also it allows flexibility and usability on fresh installs of 7 and Vista do that is another reason why I recommend it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks excellent to me as a solution for the standard ABI, but I realised in reviewing it that the stable ABI poses a potential problem: we don't want to expose the Py_tss_t
definition in that case, but making the API usable with an opaque type definition would require a few changes (details inline).
Include/pythread.h
Outdated
|
||
/* Py_tss_t is opaque type and you *must not* directly read and write. | ||
When you'd check whether the key is created, use PyThread_tss_is_created. | ||
*/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This comment should explain that the type layout is public (despite being nominally opaque) to allow for static declarations in API clients.
It should be made fully opaque when Py_LIMITED_API
is defined, though: https://docs.python.org/3/c-api/stable.html
Include/pythread.h
Outdated
PyThread_tss_is_created(Py_tss_t key) | ||
{ | ||
return key._is_initialized; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To allow for use in the Py_LIMITED_API
case, the public APIs that currently accept Py_tss_t
by value will need to accept it as a pointer instead.
The alternative would be to make the Py_tss_t
struct layout part of the stable ABI, but I'm reluctant to do that due to the NATIVE_TLS_KEY_T
field: it would keep us from switching from int
to a different native type for platforms that don't currently have a native implementation, but gain one in the future.
Following that chain of thought further, I guess fully supporting Py_LIMITED_API would require an extra pair of memory management functions (PyThread_tss_alloc
and PyThread_tss_free
), as with the struct definition hidden, API clients won't be able to use static variables.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not super-familiar with the constraints regarding Py_LIMITED_API
. Addressing this will require an update to the PEP as well.
I wouldn't mind if the functions in question were changed to take a pointer argument instead of passing the struct by value just for consistency's sake if nothing else.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, I start work to modify to full Py_LIMITED_API
on the weekend.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With a PyThread_tss_alloc
, would the need for Py_tss_NEEDS_INIT
to be public go away? After all, if one used PyThread_tss_alloc
to allocate memory for a struct, what else would they even initialize it with? It would remove an extra step to just do that as part of PyThread_tss_alloc
and remove that implementation detail.
It should just be clear that just because a TSS key has been allocated doesn't mean it's been created. Also, PyThread_tss_is_created
is still available to test whether or not a key has been created.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
static storage allocation would still be supported for the normal (non-limited API) case, so the public Py_tss_NEEDS_INIT
initializer would still be needed.
Python/thread.c
Outdated
|
||
/* Thread Local Storage (TLS) API, DEPRECATED since Python 3.7 | ||
|
||
In the own implementation, TLS API has been changed to call TSS API. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the second sentence here, I'd suggest "While the native thread-local storage implementations have been retained, this fallback implementation is now just a compatibility wrapper around the TSS API."
Python/thread_foobar.h
Outdated
|
||
void | ||
PyThread_tss_delete_value(Py_tss_t key) | ||
{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does PEP 7 express a preference regarding empty function definitions? If it doesn't we should at least make sure the TLS/TSS code is self-consistent (one of the later changes has the opening and closing brace on the same line).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not that I can tell, in which case the most consistent style would be that demonstrated here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, I'm going to make formatting even. By the way, would I create an issue for removing Python/thread_foobar.h
? Although I'm not sure history of thread_foobar.h, it seems to me that is dead code at present.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ma8ma Aye, a separate issue and python-dev thread for that sounds sensible to me. The question to the mailing list can just be something simple like "This looks like dead code and we want to delete it, does anyone have a reason we should keep it?"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had assumed it was a dummy implementation for testing / demonstration purposes. It might be an easier way to understand the requirements of the threading API without being bogged down with the details of specific implementations. That said, I don't know how useful that is in practice. I don't think I ever looked at it, opting instead to look at the pthread implementation since pthreads are already familiar...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, in fact, I think it makes the loading to maintainers. I posted to python-dev.
Include/pythread.h
Outdated
*/ | ||
|
||
#if defined(_POSIX_THREADS) | ||
# define NATIVE_TLS_KEY_T pthread_key_t |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For consistency, this should be NATIVE_TSS_KEY_T
38138e2
to
dff0a13
Compare
In Windows, the module-definition (.def) file for limited API (python3.dll) doesn't have the TSS API (also the TLS API), therefore, Edit (2017-05-13): Add WIP commit for Windows ABI |
1c98d1b
to
5b9b417
Compare
56d660b
to
23a6e59
Compare
Resolve conflicts: fdaeea6 bpo-30279: Remove unused Python/thread_foobar.h (python#1473)
Resolve conflcts: ab4413a bpo-30039: Don't run signal handlers while resuming a yield from stack (python#1081)
Resolve conflicts: 346cbd3 bpo-16500: Allow registering at-fork handlers (python#1715)
The code has been moved from Modules/signalmodule.c. (346cbd3)
Resolve conflicts: f7ecfac Doc nits for bpo-16500 (python#1841)
Resolve conflicts: 3b5cf85 bpo-30524: Write unit tests for FASTCALL (python#2022)
@ncoghlan Thank you for the explanation. I don't think there is any problem, so I add the TSS API in the Windows stable ABI. |
- overview - the existing TLS API (without descripiton) - the new TSS API - type and macro - dynamic allocation - methods
Several comments is no longer necessary by API document.
New order is along API document.
I updated this PR to add API document. Sources of the API description are:
Documents rendered by github: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is looking very good to me. I'm going to go through and make some edits to the docs updates, and add in the required limited API version check, but after that I think this should be ready to merge.
A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated. Once you have made the requested changes, please leave a comment on this pull request containing the phrase And if you don't make the requested changes, you will be put in the comfy chair! |
Oops, the required macro version check is there, it just wasn't visible in the subset of changes I was looking at - so I'll just make the docs tweaks, and then this will be ready to merge. |
Great! I was just about to say, since |
@embray I think it's good to go once the latest CI run finishes, but another set of eyes looking over the changes wouldn't hurt (if it's just docs comments though, then it would probably make sense to defer those to a new PR so we can restore Cygwin compatibility in the meantime) |
And merged - thank you @ma8ma for the PR! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do not merge until approved the PEP final!Update (2017-09-09): PEP 539 has been accepted.
Thread Specific Storage (TSS) API
Implement PEP 539 for Thread Specific Stroage (TSS) API: it is a new Thread Local Storage (TLS) API to CPython which would supersede use of the existing TLS API within the CPython interpreter, while deprecating the existing API.
Highlights of changes
[TEMP] Add an example function toxxlimited
modulehttps://bugs.python.org/issue25658