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
Native TLS support for pthreads #53995
Comments
The following patch adds native TLS implementation for pthreads, avoiding the relatively slow and clunky default tls implemented in thread.c |
The patch looks good. |
Just tried to apply the patch:
|
The code may need a little bit of extra work: The pthreads machine that I have to work with is a PS3 :). I'll do some tests and let you know. |
"errno" is preserved by PyEval_RestoreThread(), so this isn't the issue. |
Hm, both the test you mention are using the (non-recursive) lock to synchronize threads. I can't see anything wrong there. Could you please try to replace the cod in pthread_getspecific() with this: int err = errno
void *result = pthread_getspecific(key);
errno = err;
return result; If this fixes those cases, then there is code somewhere that relies on errno being maintained across these calls. |
The problem turns out to be in pystate.c (my system returns 0 as a valid key number). See issue bpo-9797. |
Ah, good to hear. |
The ifdef should go; pthreads always support TLS (since XPG5, 1997). |
I left the ifdef in for a quick and easy way to disable this code for those interested, but I'm happy to remove it if it makes for greater synergy. |
Added a new patch with #ifdef remvoved, for greater harmony. |
It seems we need to clarify the return value of PyThread_create_key. The patch returns 0 in case of failure, which is clearly wrong as 0 is also a valid key. I think it's safe to return -1: TlsAlloc returns TLS_OUT_OF_INDEXES, which is 0xFFFFFFFF, i.e. -1 on a 32-bit system. |
I've changed the function as you suggest, although there are in fact no failure detection semantics defined for PyThread_create_key(). See e.g. thread.c:294 /* Return a new key. This must be called before any other functions in
* this family, and callers must arrange to serialize calls to this
* function. No violations are detected.
*/
int
PyThread_create_key(void) |
Am 13.09.2010 10:00, schrieb Kristján Valur Jónsson:
Right. That's why I'm thinking that we should introduce some. TLS In principle, this is really difficult to get right. AFAICT, |
Perhaps we can simply call Py_FatalError() instead? There's not much we |
Sounds fine as well. Python's own usage definitely shouldn't fail. If |
Ok, here is a patch. key creation returns -1 on error, and the caller can detect this and raise a fatal error. |
Patch looks good to me. |
Committed as revision 84914 |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: