Antoine Pitrou pit...@free.fr added the comment:
Patch looks good to me.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9786
___
___
Kristján Valur Jónsson krist...@ccpgames.com added the comment:
Committed as revision 84914
--
resolution: - accepted
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9786
Kristján Valur Jónsson krist...@ccpgames.com 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
___
Martin v. Löwis mar...@v.loewis.de 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
Kristján Valur Jónsson krist...@ccpgames.com 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
Martin v. Löwis mar...@v.loewis.de added the comment:
Am 13.09.2010 10:00, schrieb Kristján Valur Jónsson:
Kristján Valur Jónsson krist...@ccpgames.com added the comment:
I've changed the function as you suggest, although there are in fact no
failure detection semantics defined for
Martin v. Löwis mar...@v.loewis.de 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,
Martin v. Löwis mar...@v.loewis.de added the comment:
The ifdef should go; pthreads always support TLS (since XPG5, 1997).
--
nosy: +loewis
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9786
Kristján Valur Jónsson krist...@ccpgames.com 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
Kristján Valur Jónsson krist...@ccpgames.com 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 rep...@bugs.python.org
Kristján Valur Jónsson krist...@ccpgames.com 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
Antoine Pitrou pit...@free.fr 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 rep...@bugs.python.org
Kristján Valur Jónsson krist...@ccpgames.com added the comment:
Ah, good to hear.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9786
___
___
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9786
___
___
Amaury Forgeot d'Arc amaur...@gmail.com 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 rep...@bugs.python.org
Antoine Pitrou pit...@free.fr 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 rep...@bugs.python.org
Kristján Valur Jónsson krist...@ccpgames.com 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
Kristján Valur Jónsson krist...@ccpgames.com 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
New submission from Kristján Valur Jónsson krist...@ccpgames.com:
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
19 matches
Mail list logo
