[issue9786] Native TLS support for pthreads

Kristján Valur Jónsson added the comment: Committed as revision 84914 -- resolution: -> accepted status: open -> closed ___ Python tracker ___ __

[issue9786] Native TLS support for pthreads

Antoine Pitrou added the comment: Patch looks good to me. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: ht

[issue9786] Native TLS support for pthreads

Kristján Valur Jónsson added the comment: Ok, here is a patch. key creation returns -1 on error, and the caller can detect this and raise a fatal error. -- Added file: http://bugs.python.org/file18906/pthread_tls.patch ___ Python tracker

[issue9786] Native TLS support for pthreads

Martin v. Löwis added the comment: > Perhaps we can simply call Py_FatalError() instead? There's not much we > can do when such a failure occurs anyway. Sounds fine as well. Python's own usage definitely shouldn't fail. If extension modules use this in an aggressive manner, they may actually ex

[issue9786] Native TLS support for pthreads

Antoine Pitrou added the comment: > Right. That's why I'm thinking that we should introduce some. TLS > creation *can* fail, and it is unfortunate that the original > introduction of this API forgot to consider that. Your patch did > (de facto) introduce an error return code (originally 0, now -

[issue9786] Native TLS support for pthreads

Martin v. Löwis added the comment: Am 13.09.2010 10:00, schrieb Kristján Valur Jónsson: > > Kristján Valur Jónsson added the comment: > > I've changed the function as you suggest, although there are in fact no > failure detection semantics defined for PyThread_create_key(). Right. That's

[issue9786] Native TLS support for pthreads

Kristján Valur Jónsson added the comment: 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 ca

[issue9786] Native TLS support for pthreads

Martin v. Löwis added the comment: 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 0x, i.e. -1 on

[issue9786] Native TLS support for pthreads

Kristján Valur Jónsson added the comment: Added a new patch with #ifdef remvoved, for greater harmony. -- Added file: http://bugs.python.org/file18864/pthread_tls.patch ___ Python tracker __

[issue9786] Native TLS support for pthreads

Kristján Valur Jónsson added the comment: 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. -- ___ Python tracker _

[issue9786] Native TLS support for pthreads

Martin v. Löwis added the comment: The ifdef should go; pthreads always support TLS (since XPG5, 1997). -- nosy: +loewis ___ Python tracker ___ __

[issue9786] Native TLS support for pthreads

Changes by Giampaolo Rodola' : -- nosy: +giampaolo.rodola ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http:/

[issue9786] Native TLS support for pthreads

Kristján Valur Jónsson added the comment: Ah, good to hear. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue9786] Native TLS support for pthreads

Antoine Pitrou added the comment: The problem turns out to be in pystate.c (my system returns 0 as a valid key number). See issue #9797. -- dependencies: +wrong assumption in pystate.c ___ Python tracker _

[issue9786] Native TLS support for pthreads

Kristján Valur Jónsson added the comment: 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(

[issue9786] Native TLS support for pthreads

Kristján Valur Jónsson added the comment: "errno" is preserved by PyEval_RestoreThread(), so this isn't the issue. What you are probably seeing is latent race conditions in the test suite, made apparent by a non-locking TLS implementation. The test suite isn't free from those, see for example

[issue9786] Native TLS support for pthreads

Kristján Valur Jónsson added the comment: The code may need a little bit of extra work: The pthreads machine that I have to work with is a PS3 :). And, despite the documentation not saying, I suspect that pthread_getspecific() actually does mess with "errno", making it necessary to preserve "

[issue9786] Native TLS support for pthreads

Antoine Pitrou added the comment: Just tried to apply the patch: - test_capi now freezes in auto-thread-state - test_threading now freezes in test_finalize_runnning_thread -- nosy: +pitrou ___ Python tracker __

[issue9786] Native TLS support for pthreads

Amaury Forgeot d'Arc added the comment: The patch looks good. Apart from PyGILState_Ensure(), are there other parts of the code that use these functions? -- nosy: +amaury.forgeotdarc ___ Python tracker ___

[issue9786] Native TLS support for pthreads

New submission from Kristján Valur Jónsson : The following patch adds native TLS implementation for pthreads, avoiding the relatively slow and clunky default tls implemented in thread.c -- components: Interpreter Core files: pthread_tls.patch keywords: needs review, patch, patch message