classification
Title: interruption of locks by signals not guaranteed when locks are implemented using POSIX condition variables; add sys.thread_info
Type: behavior Stage:
Components: Interpreter Core, Tests Versions: Python 3.2
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: benjamin.peterson, db3l, gregory.p.smith, haypo, neologix, pitrou, python-dev, rnk, sable
Priority: normal Keywords: patch

Created on 2011-02-16 14:25 by sable, last changed 2011-06-23 12:22 by python-dev. This issue is now closed.

Files
File name Uploaded Description Edit
test_threadsignals.patch pitrou, 2011-02-16 15:27 review
pthread_cond_timedwait_signal.c haypo, 2011-04-19 09:39
threading_info.patch haypo, 2011-04-19 10:30 review
threading_info-2.patch haypo, 2011-04-19 15:34 review
threading_info-3.patch haypo, 2011-04-19 21:19 review
sys_thread_info.patch haypo, 2011-04-20 23:15 review
sys_thread_info-2.patch haypo, 2011-04-26 21:48 review
Messages (41)
msg128668 - (view) Author: Sébastien Sablé (sable) Date: 2011-02-16 14:25
The test test_lock_acquire_interruption in test_threadsignals.py will lock forever on AIX 5.3.
It works fine on 6.1.

truss shows it is stuck in thread_tsleep:
$ truss -p 1404986
thread_tsleep(0, 0x00000000, 0x00000000, 0x00000000) (sleeping...)
msg128669 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-02-16 14:51
We have the same issue on our FreeBSD 6.4 buildbot:
http://python.org/dev/buildbot/all/builders/x86%20FreeBSD%203.x/builds/1216/steps/test/logs/stdio
(FreeBSD 7.2 is fine)

Can you tell me what the values of _POSIX_SEMAPHORES and HAVE_SEM_TIMEDWAIT are (or whether they are undefined)?
msg128670 - (view) Author: Sébastien Sablé (sable) Date: 2011-02-16 15:03
$ grep SEM pyconfig.h
#define HAVE_BROKEN_POSIX_SEMAPHORES 1
/* #undef HAVE_BROKEN_SEM_GETVALUE */
#define HAVE_SEM_GETVALUE 1
#define HAVE_SEM_OPEN 1
#define HAVE_SEM_TIMEDWAIT 1
#define HAVE_SEM_UNLINK 1
/* #undef POSIX_SEMAPHORES_NOT_ENABLED */
#ifndef _POSIX_PTHREAD_SEMANTICS
# define _POSIX_PTHREAD_SEMANTICS 1
msg128672 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-02-16 15:16
Ok, the problem is when the condition variable-based implementation is chosen in Python/thread_pthread.h.
It is actually reproduceable under Linux by adding `#undef USE_SEMAPHORES` just after `#define USE_SEMAPHORES`.
The problem is that, contrary to sem_timedwait(), pthread_cond_wait() doesn't have well-defined behaviour with signals. POSIX simply says:

“If a signal is delivered to a thread waiting for a condition variable, upon return from the signal handler the thread resumes waiting for the condition variable as if it was not interrupted, or it shall return zero due to spurious wakeup.”

So, on those OSes where the semaphore API can't be used, the test can succeed or not depending on how pthread_cond_wait() behaves in the face of signals. It would be better if it didn't hang, though.

(This is not a regression, by the way. Locks were totally uninterruptible under POSIX until 3.2, and the tests weren't there. The new tests were introduced in r87292 (see issue8844))
msg128674 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-02-16 15:27
Here is a patch that makes the test fail rather than hang. Sébastien, can you try it out?
msg128675 - (view) Author: Sébastien Sablé (sable) Date: 2011-02-16 15:41
Thanks Antoine, the patch solved the problem.

I have other tests locking semi-randomly on AIX 5.3 and/or AIX 6.1, like test_socket and test_io. That may be related.
msg128676 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-02-16 15:43
> I have other tests locking semi-randomly on AIX 5.3 and/or AIX 6.1,
> like test_socket and test_io. That may be related.

Which test cases exactly?
msg128677 - (view) Author: Sébastien Sablé (sable) Date: 2011-02-16 16:24
Well I don't know precisely:

* when running make buildbottest, test_socket will systematically hang on AIX 5.3 and 6.1.

* but when running ./python -Wd -E -bb Lib/test/test_socket.py, the tests complete rather quickly (with one failure cf 11192).

Ran 158 tests in 16.867s

FAILED (failures=1, skipped=4)

I will try with pdb or something.
msg128678 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-02-16 16:27
> Well I don't know precisely:
> 
> * when running make buildbottest, test_socket will systematically hang
> on AIX 5.3 and 6.1.
> 
> * but when running ./python -Wd -E -bb Lib/test/test_socket.py, the
> tests complete rather quickly (with one failure cf 11192).

You can run the whole test suite in verbose mode. This will pollute your
terminal a lot, but you'll see exactly where it hangs.

Try something like "./python -E -bb -m test.regrtest -uall -v"
msg128680 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2011-02-16 16:55
> I will try with pdb or something.

You can also try to attach gdb to the running process: with
python-gdb.py, you have nice py-* commands.

Or if you don't have gdb7, you may try my faulthandler module: you will
have to modify the source code (eg. Lib/test/regrtest.py) to add at the
top:

   import faulthandler, signal; faulthandler.register(signal.SIGUSR1)

Then you can display the current Python backtrace by sending a SIGUSR1
signal to the running Python process (eg. killall -USR1 python).

https://github.com/haypo/faulthandler/wiki
msg128681 - (view) Author: Sébastien Sablé (sable) Date: 2011-02-16 16:55
test_socket didnot lock this time (I will retry next).

But test_subprocess.ProcessTestCasePOSIXPurePython.test_leaking_fds_on_error did.

Looping forever on the following syscall:

pipe(0x2FF1FD88)                                = 0
kfcntl(15, F_GETFD, 0x00000000)                 = 0
kfcntl(15, F_SETFD, 0x00000001)                 = 0
kfcntl(17, F_GETFD, 0x00000000)                 = 0
kfcntl(17, F_SETFD, 0x00000001)                 = 0
pipe(0x2FF1FD88)                                = 0
kfcntl(18, F_GETFD, 0x00000000)                 = 0
kfcntl(18, F_SETFD, 0x00000001)                 = 0
kfcntl(19, F_GETFD, 0x00000000)                 = 0
kfcntl(19, F_SETFD, 0x00000001)                 = 0
fstatx(15, 0x2FF1FAEC, 76, 0)                   = 0
kioctl(15, 22528, 0x00000000, 0x00000000)       Err#25 ENOTTY
fstatx(15, 0x2FF1FD7C, 76, 0)                   = 0
lseek(15, 0, 1)                                 Err#29 ESPIPE
fstatx(18, 0x2FF1FAEC, 76, 0)                   = 0
kioctl(18, 22528, 0x00000000, 0x00000000)       Err#25 ENOTTY
fstatx(18, 0x2FF1FD7C, 76, 0)                   = 0
lseek(18, 0, 1)                                 Err#29 ESPIPE
pipe(0x2FF1FD08)                                = 0
kfcntl(20, F_GETFD, 0x00000000)                 = 0
kfcntl(20, F_SETFD, 0x00000001)                 = 0
kfcntl(21, F_GETFD, 0x00000000)                 = 0
kfcntl(21, F_SETFD, 0x00000001)                 = 0
sigprocmask(0, 0xF029C148, 0xF029C150)          = 0
kfork()                                         = 2011158
thread_setmymask_fast(0x00000000, 0x00000000, 0x00000000, 0xD0504100, 0x00000000, 0x1216F00B, 0x1216F00B, 0x00000000) = 0x00000000
close(21)                                       = 0
close(17)                                       = 0
close(19)                                       = 0
kread(20, " O S E r r o r : 2 :\0 i".., 50000)  = 10
kread(20, 0x33041C38, 50000)                    = 0
close(20)                                       = 0
kwaitpid(0x2FF1FB50, 2011158, 4, 0x00000000, 0x00000000) = 2011158
close(15)                                       = 0
close(18)                                       = 0
close(15)                                       Err#9  EBADF
close(18)                                       Err#9  EBADF
pipe(0x2FF1FD88)                                = 0
msg128718 - (view) Author: Sébastien Sablé (sable) Date: 2011-02-17 10:44
Here is what faulthandler reports when I trigger it as Python is locked in test_socket:

"""
[108/349] test_socket
Traceback (most recent call first):
  File "/san_cis/home/cis/.buildbot/python-aix6/3.x.phenix.xlc/build/Lib/test/fork_wait.py", line 30 in f
""" (sic)

It is coherent with what truss tells:
_getpid()                                       = 1474634
_select(0, 0x00000000, 0x00000000, 0x00000000, 0x317535F0) = 0
_getpid()                                       = 1474634
_select(0, 0x00000000, 0x00000000, 0x00000000, 0x315E35F0) = 0
....

And we can find this comment in the file:
# waitpid() shouldn't hang, but some of the buildbots seem to hang
# in the forking tests.  This is an attempt to fix the problem.
msg128719 - (view) Author: Sébastien Sablé (sable) Date: 2011-02-17 10:47
faulthandler is great by the way! I will use that in my application.
msg128720 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2011-02-17 10:55
> Here is what faulthandler reports when I trigger it as Python
> is locked in test_socket:
> ...
>  File ".../Lib/test/fork_wait.py", line 30 in f

faulthandler doesn't print the source code line (yet?). Here is the code:

class ForkWait(unittest.TestCase):
    ...
    def f(self, id):
        while not self.stop:
            self.alive[id] = os.getpid()
            try:
                time.sleep(SHORTSLEEP) <~~~ here
            except IOError:
                pass

ForkWait.f() is used by ForkWait.test_wait() which creates 4 threads. You may use all_threads=True option of faulthandler to get the backtrace of all threads.

Because ForkWait.test_wait() uses fork, you may also need to dump the backtrace of two processes.

Debug threads+multiple processes is something horrible :-)
msg128721 - (view) Author: Sébastien Sablé (sable) Date: 2011-02-17 10:59
At the time of the lock, there is only one python process running. So I guess the other processes have already left but this is not correctly detected.

I will try again with all_threads=True.
msg128722 - (view) Author: Sébastien Sablé (sable) Date: 2011-02-17 11:07
I kinda feel this is related to issue 11185 which I reported earlier.
msg128723 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-02-17 11:17
Could you open another issue? (or post in issue 11185 above)
msg130755 - (view) Author: Roundup Robot (python-dev) Date: 2011-03-13 18:16
New changeset 5d0d488cbca8 by Antoine Pitrou in branch '3.2':
Issue #11223: Fix test_threadsignals to fail, not hang, when the
http://hg.python.org/cpython/rev/5d0d488cbca8
msg134028 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2011-04-19 09:38
> “If a signal is delivered to a thread waiting for a condition variable, 
> upon return from the signal handler the thread resumes waiting for the condition
> variable as if it was not interrupted, or it shall return zero due to spurious
> wakeup.”

Confirmed on Linux (kernel 2.6.37, eglibc 2.11.2) using strace:
--------
10:42:59.942455 futex(0x173fabc, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1, {1303202584, 942432000}, ffffffff) = ? ERESTART_RESTARTBLOCK (To be restarted)
10:43:00.941777 --- SIGALRM (Alarm clock) @ 0 (0) ---
10:43:00.941848 rt_sigreturn(0x1462eac) = -1 EINTR (Interrupted system call)
10:43:00.941926 futex(0x173fabc, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1, {1303202584, 942432000}, ffffffff) = -1 ETIMEDOUT (Connection timed out)
10:43:04.942650 futex(0x173fae8, FUTEX_WAKE_PRIVATE, 1) = 0
--------
pthread_cond_timedwait() is interrupted: the system call returns ERESTART_RESTARTBLOCK (To be restarted), and then the system call is restarted.

I think that we should just skip the test if Python uses pthread without semaphore and pthread_cond_timedwait() restarts if it is interrupted by a signal. Attached C program checks if pthread_cond_timedwait() does restart or not. On Linux, it should be compiled using:
gcc -pthread -lrt pthread_cond_timedwait_signal.c -o pthread_cond_timedwait_signal

I don't know how to integrate pthread_cond_timedwait_signal.c into configure.in. I don't know if any OS does NOT restart pthread_cond_timedwait() after an interruption, so it's maybe simpler to always skip test_lock_acquire_interruption() and test_rlock_acquire_interruption() of test_threadsignals if Python uses pthread without semaphore.
msg134031 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2011-04-19 10:01
The problem is that I don't know how to check in test_threadsignals which thread implementation is used in Python. It would be nice to have some functions providing such information in the sys or sysconfig module, maybe something like sys.float_info.

For example, sys._thread_info can be a dict like {'name': 'pthread', 'use_semaphore': True}.

Keys:
 - name: cthread, lwp, nt, os2, pth, pthread, sgi, solaris or wince (sgi, lwp, pth, cthread may be removed from Python 3.3: #11876)
 - maxproc: max # of threads that can be started (SGI only)
 - stacksize: default stacksize for a thread (lwp, pthread and os2 only)
 - min_stacksize: minimum stacksize for a thread (pthread, nt and os2 only)
 - max_stacksize: maximum stacksize for a thread (nt and os2 only)

thread_pthread.h contains many #ifdef which may be interesting to have in thread_info:
 - if _HAVE_BSDI is defined, don't use pthread_init()
 - if THREAD_STACK_SIZE is defined, set the size of the thread stack
 - if PTHREAD_SYSTEM_SCHED_SUPPORTED is defined: set scope to PTHREAD_SCOPE_SYSTEM
 - if (defined(_POSIX_SEMAPHORES) && defined(HAVE_BROKEN_POSIX_SEMAPHORES) && defined(HAVE_SEM_TIMEDWAIT)): use semaphore

Well, the most important informations for this issue is the name of the thread implementation (pthread) and know if pthread semaphore are used or not.
msg134037 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2011-04-19 10:30
threading_info.patch:
 - Add thread._info() function -> dict with 'name' and 'use_semaphores' (pthread only) keys
 - Skip test_lock_acquire_interruption() and test_rlock_acquire_interruption() if Python uses pthread without semaphores

thread._info() creates a new dict at each call.
msg134049 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-04-19 13:08
> threading_info.patch:
>  - Add thread._info() function -> dict with 'name' and
> 'use_semaphores' (pthread only) keys

Most of these names will be removed in 3.3:
http://bugs.python.org/issue11863
msg134068 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2011-04-19 15:34
> Most of these names will be removed in 3.3:
> http://bugs.python.org/issue11863

Yeah, I know. My patch should be updated if #11863 is fixed before this issue.

Updated patch:
 - add 'pthread_version' key to threading._info()
 - test_os uses threading._info() to check if we are using linuxthreads
msg134069 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2011-04-19 15:37
Example on my Debian Sid:

>>> threading._info()
{'pthread_version': 'NPTL 2.11.2', 'use_semaphores': True, 'name': 'pthread'}
msg134070 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-04-19 15:42
> Yeah, I know. My patch should be updated if #11863 is fixed before this issue.
> 
> Updated patch:
>  - add 'pthread_version' key to threading._info()
>  - test_os uses threading._info() to check if we are using linuxthreads

The path which sets "pthread_version" should be inside "#ifdef
_POSIX_THREADS".

Also, some comments about the doc:
- you need a "versionadded" tag
- "use_semaphores" should explain that these semaphores are used for
locks; also the alternative is "use mutexes and condition variables",
not "use mutexes"
- you should not document unsupported platform names ("lwp", etc.); they
are already disabled (#error)
msg134104 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2011-04-19 21:19
> The path which sets "pthread_version" should be inside "#ifdef
> _POSIX_THREADS".
> Also, some comments about the doc:
> - you need a "versionadded" tag

Right, fixed.

> - "use_semaphores" should explain that these semaphores are used for
> locks; also the alternative is "use mutexes and condition variables",
> not "use mutexes"

Hum, a boolean was not a good idea. I replaced this key by:

 * 'lock' (string): name of the lock implementation

   * 'semaphore': a lock uses a semaphore
   * 'mutex+cond': a lock uses a mutex and a condition variable

I also renamed 'name' key to 'thread', so 'thread' is the name of the
*thread* implementation, and 'lock' is the name of the *lock*
implementation.

For example, test_threadsignals now uses:
-----------
USING_PTHREAD_COND = (info['thread'] == 'pthread'
                      and info['lock'] == 'mutex+cond')
...
@unittest.skipIf(USING_PTHREAD_COND,
                 'POSIX condition variables cannot be interrupted')
-----------

I think that the test is more clear than:
-----------
@unittest.skipIf(info['name'] == 'pthread' and not
info['use_semaphores'],
                'POSIX mutexes cannot be interrupted')
-----------

(the message was wrong, the interrupt issue is on the condition, not on
the mutex)

> - you should not document unsupported platform names ("lwp", etc.); they
> are already disabled (#error)

Oh, I didn't realize that they were already unsupported as a compilation
error. Ok, fixed. I also removed "wince": I realized that thread_wince.h
is not used (see #11863).

The new patch (version 3) marks also PyThread_Info() as private (rename
it to _PyThread_Info).
msg134105 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-04-19 21:27
> I also renamed 'name' key to 'thread', so 'thread' is the name of the
> *thread* implementation, and 'lock' is the name of the *lock*
> implementation.

Not that I want to bikeshed, but I think 'name' was ok (since you get
the dict by calling threading._info(), it's obvious it has to do with
threading).
'lock_implementation' would be better than 'lock', OTOH.

Also, the 'pthread_version' documentation should state that it is
optional (only works on GNU).
msg134106 - (view) Author: Roundup Robot (python-dev) Date: 2011-04-19 21:59
New changeset 383a7301616b by Victor Stinner in branch 'default':
Issue #11223: Add threading._info() function providing informations about the
http://hg.python.org/cpython/rev/383a7301616b
msg134107 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2011-04-19 22:06
Let's wait 6 hours for "x86 FreeBSD 6.4 3.x":
http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%206.4%203.x

The first build including my fix (383a7301616b) should be:
http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%206.4%203.x/builds/1395
msg134108 - (view) Author: Roundup Robot (python-dev) Date: 2011-04-19 22:28
New changeset bc1c6bd7eeb0 by Victor Stinner in branch 'default':
Issue #11223: fix test_dummy_threading, add _dummy_thread.info()
http://hg.python.org/cpython/rev/bc1c6bd7eeb0
msg134131 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2011-04-20 08:30
"Builder x86 FreeBSD 6.4 3.x Build #1394. Results: Build successful"
http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%206.4%203.x/builds/1394

Great! It should be the first success on this buildbot since... 4 months (r87292, issue #8844))? Let's close this issue.
msg134135 - (view) Author: Roundup Robot (python-dev) Date: 2011-04-20 10:24
New changeset 64008d17fb54 by Victor Stinner in branch 'default':
Issue #11223: fix compiler warnings
http://hg.python.org/cpython/rev/64008d17fb54
msg134189 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2011-04-20 23:15
sys_thread_info.patch:
 - Replace threading._info() by sys.thread_info: it now always have 3 values, but all values are optional (can be None). sys.thread_info.name is None if Python is compiled without threads.
 - Reorder sys internal doc (Static objects) and replace "dict" by "struct sequence" for float_info
 - Rename _PyThread_Info() to PyThread_GetInfo() (consistent name with PyFloat_GetInfo() and PyLong_GetInfo())
 - Always compile thread.c, but add #ifdef WITH_THREAD around most the file (except PyThread_GetInfo())

Example:

>>> sys.thread_info
sys.thread_info(name='pthread', lock='semaphore', version='NPTL 2.11.2')
msg134191 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-04-20 23:20
>  - Rename _PyThread_Info() to PyThread_GetInfo() (consistent name with
> PyFloat_GetInfo() and PyLong_GetInfo())

I don't think we want that API to be public, so it should be
_PyThread_GetInfo().

>  - Always compile thread.c, but add #ifdef WITH_THREAD around most the
> file (except PyThread_GetInfo())

What's the point? Sounds like pointless complication.
msg134435 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2011-04-26 01:34
> >  - Rename _PyThread_Info() to PyThread_GetInfo() (consistent name with
> > PyFloat_GetInfo() and PyLong_GetInfo())
> 
> I don't think we want that API to be public, so it should be
> _PyThread_GetInfo().

Why should it be private in C, but not in Python?

Why should it be private whereas PyLong_GetInfo() and PyFloat_GetInfo()
are public?

> >  - Always compile thread.c, but add #ifdef WITH_THREAD around most the
> > file (except PyThread_GetInfo())
> 
> What's the point? Sounds like pointless complication.

Complication? It does *simplify* configure.in.

I don't want to create a new file just for a small function.
msg134484 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-04-26 17:43
Le mardi 26 avril 2011 à 01:34 +0000, STINNER Victor a écrit :
> STINNER Victor <victor.stinner@haypocalc.com> added the comment:
> 
> > >  - Rename _PyThread_Info() to PyThread_GetInfo() (consistent name with
> > > PyFloat_GetInfo() and PyLong_GetInfo())
> > 
> > I don't think we want that API to be public, so it should be
> > _PyThread_GetInfo().
> 
> Why should it be private in C, but not in Python?

Well, if it's called _info() in Python, it's private too!

> > >  - Always compile thread.c, but add #ifdef WITH_THREAD around most the
> > > file (except PyThread_GetInfo())
> > 
> > What's the point? Sounds like pointless complication.
> 
> Complication? It does *simplify* configure.in.
> 
> I don't want to create a new file just for a small function.

What I mean is that the "#ifdef WITH_THREAD" could be done in
sysmodule.c rather than in thread.c

Also, when Python is compiled without threads, I don't think thread_info
should be a structseq. It should probably be None instead.

Another small thing: your doc says "name" is optional, but it shouldn't.
msg134505 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2011-04-26 21:48
> Well, if it's called _info() in Python, it's private too!

My patch replaces thread._info() by sys.thread_info: it becomes public.

> What I mean is that the "#ifdef WITH_THREAD" could be done in
> sysmodule.c rather than in thread.c

PyThread_GetInfo() requires some informations that are only available at the end of thread.c: USE_SEMAPHORES define from thread_pthread.h and PYTHREAD_NAME from thread.c. It is easier to define PyThread_GetInfo() here, instead of giving access to these defines outside thread.c (and these defines should remaing private).

> Another small thing: your doc says "name" is optional, but it shouldn't.

By optional I mean that its value is None if Python is compiled without threads.

> Also, when Python is compiled without threads, 
> I don't think thread_info should be a structseq. 
> It should probably be None instead.

Terry Reedy proposed an empty string for name if Python is compiled without threads. Antoine suggested None instead of an empty string for lock and version fields, so I chose to use also None for None.

But yes, I like the idea of sys.thread_info being None.

--

Updated patch (sys_thread_info-2.patch):
 - sys.thread_info is None if Python is compiled without threads
 - sys.thread_info.name is no more optional
 - change the documentation of the lock and version fields
 - fix test_os (version is now a attribute and no more a key of a dict)
msg134859 - (view) Author: Roundup Robot (python-dev) Date: 2011-04-30 13:01
New changeset 2b21fcf3d9a9 by Victor Stinner in branch 'default':
Issue #11223: Replace threading._info() by sys.thread_info
http://hg.python.org/cpython/rev/2b21fcf3d9a9
msg138862 - (view) Author: Roundup Robot (python-dev) Date: 2011-06-23 09:57
New changeset 07655b3dee4f by Victor Stinner in branch '3.2':
Issue #11223: skip test_lock_acquire_interruption() on FreeBSD6
http://hg.python.org/cpython/rev/07655b3dee4f
msg138863 - (view) Author: Roundup Robot (python-dev) Date: 2011-06-23 09:59
New changeset 3f18a03a2a1e by Victor Stinner in branch 'default':
(null merge 3.2 for issue #11223) python 3.3 has already a better fix
http://hg.python.org/cpython/rev/3f18a03a2a1e
msg138864 - (view) Author: Roundup Robot (python-dev) Date: 2011-06-23 12:22
New changeset e5183f16c49d by Victor Stinner in branch '3.2':
Issue #11223: skip also test_rlock_acquire_interruption() on FreeBSD6
http://hg.python.org/cpython/rev/e5183f16c49d

New changeset 54fb77e0762c by Victor Stinner in branch 'default':
(null merge 3.2 for issue #11223) python 3.3 has already a better fix
http://hg.python.org/cpython/rev/54fb77e0762c
History
Date User Action Args
2011-06-23 12:22:50python-devsetmessages: + msg138864
2011-06-23 09:59:07python-devsetmessages: + msg138863
2011-06-23 09:57:53python-devsetmessages: + msg138862
2011-04-30 13:01:53python-devsetmessages: + msg134859
2011-04-30 12:53:54hayposettitle: interruption of locks by signals not guaranteed when locks are implemented using POSIX condition variables -> interruption of locks by signals not guaranteed when locks are implemented using POSIX condition variables; add sys.thread_info
2011-04-26 21:48:11hayposetfiles: + sys_thread_info-2.patch

messages: + msg134505
2011-04-26 17:43:09pitrousetmessages: + msg134484
2011-04-26 01:34:42hayposetmessages: + msg134435
2011-04-20 23:20:24pitrousetmessages: + msg134191
2011-04-20 23:15:21hayposetfiles: + sys_thread_info.patch
nosy: + benjamin.peterson
messages: + msg134189

2011-04-20 10:26:07hayposettitle: interruption of locks by signals not guaranteed when the semaphore implementation is not used -> interruption of locks by signals not guaranteed when locks are implemented using POSIX condition variables
2011-04-20 10:24:05python-devsetmessages: + msg134135
2011-04-20 08:30:34hayposetstatus: open -> closed
resolution: fixed
messages: + msg134131
2011-04-19 22:28:37python-devsetmessages: + msg134108
2011-04-19 22:06:37hayposetmessages: + msg134107
2011-04-19 21:59:27python-devsetmessages: + msg134106
2011-04-19 21:27:33pitrousetmessages: + msg134105
2011-04-19 21:19:41hayposetfiles: + threading_info-3.patch

messages: + msg134104
2011-04-19 15:42:06pitrousetmessages: + msg134070
2011-04-19 15:37:15hayposetmessages: + msg134069
2011-04-19 15:34:21hayposetfiles: + threading_info-2.patch

messages: + msg134068
2011-04-19 13:08:45pitrousetmessages: + msg134049
2011-04-19 10:30:14hayposetfiles: + threading_info.patch

messages: + msg134037
2011-04-19 10:01:37hayposetmessages: + msg134031
2011-04-19 09:39:45hayposetfiles: + pthread_cond_timedwait_signal.c
2011-04-19 09:38:58hayposetmessages: + msg134028
2011-03-13 18:16:11python-devsetnosy: + python-dev
messages: + msg130755
2011-03-06 10:01:16pitrousetnosy: + neologix
2011-02-17 11:17:48pitrousetnosy: gregory.p.smith, db3l, pitrou, haypo, sable, rnk
messages: + msg128723
2011-02-17 11:07:30sablesetnosy: gregory.p.smith, db3l, pitrou, haypo, sable, rnk
messages: + msg128722
2011-02-17 10:59:31sablesetnosy: gregory.p.smith, db3l, pitrou, haypo, sable, rnk
messages: + msg128721
2011-02-17 10:55:13hayposetnosy: gregory.p.smith, db3l, pitrou, haypo, sable, rnk
messages: + msg128720
2011-02-17 10:47:15sablesetnosy: gregory.p.smith, db3l, pitrou, haypo, sable, rnk
messages: + msg128719
2011-02-17 10:44:47sablesetnosy: gregory.p.smith, db3l, pitrou, haypo, sable, rnk
messages: + msg128718
2011-02-16 16:55:34sablesetnosy: gregory.p.smith, db3l, pitrou, haypo, sable, rnk
messages: + msg128681
2011-02-16 16:55:04hayposetnosy: gregory.p.smith, db3l, pitrou, haypo, sable, rnk
messages: + msg128680
2011-02-16 16:27:56pitrousetnosy: gregory.p.smith, db3l, pitrou, haypo, sable, rnk
messages: + msg128678
2011-02-16 16:24:10sablesetnosy: gregory.p.smith, db3l, pitrou, haypo, sable, rnk
messages: + msg128677
2011-02-16 15:43:10pitrousetnosy: gregory.p.smith, db3l, pitrou, haypo, sable, rnk
messages: + msg128676
2011-02-16 15:41:37pitrousetnosy: + db3l
2011-02-16 15:41:03sablesetnosy: gregory.p.smith, pitrou, haypo, sable, rnk
messages: + msg128675
2011-02-16 15:40:47pitroulinkissue10720 superseder
2011-02-16 15:27:28pitrousetfiles: + test_threadsignals.patch
title: test_threadsignals.py hanging on AIX -> interruption of locks by signals not guaranteed when the semaphore implementation is not used
nosy: gregory.p.smith, pitrou, haypo, sable, rnk
messages: + msg128674

keywords: + patch
2011-02-16 15:16:35pitrousetnosy: + gregory.p.smith, rnk
messages: + msg128672

components: + Interpreter Core, Tests
type: behavior
2011-02-16 15:03:38sablesetnosy: pitrou, haypo, sable
messages: + msg128670
2011-02-16 14:58:27hayposetnosy: + haypo
2011-02-16 14:51:18pitrousetnosy: + pitrou
messages: + msg128669
2011-02-16 14:25:35sablecreate