Mailman 3 March 2012 - Python-checkins

cpython (2.7): Issue #14437: Fix building the _io module under Cygwin.
by antoine.pitrou March 31, 2012

March 31, 2012

http://hg.python.org/cpython/rev/6f8dd543d80a changeset: 76032:6f8dd543d80a branch: 2.7 parent: 76020:3ca81a951c31 user: Antoine Pitrou <solipsis(a)pitrou.net> date: Sat Mar 31 23:53:07 2012 +0200 summary: Issue #14437: Fix building the _io module under Cygwin. files: Misc/NEWS | 5 +++++ Modules/_io/_iomodule.h | 2 +- 2 files changed, 6 insertions(+), 1 deletions(-) diff --git a/Misc/NEWS b/Misc/NEWS --- a/Misc/NEWS +++ b/Misc/NEWS @@ -78,6 +78,11 @@ - Issue #6884: Fix long-standing bugs with MANIFEST.in parsing in distutils on Windows. +Build +----- + +- Issue #14437: Fix building the _io module under Cygwin. + What's New in Python 2.7.3 release candidate 2? =============================================== diff --git a/Modules/_io/_iomodule.h b/Modules/_io/_iomodule.h --- a/Modules/_io/_iomodule.h +++ b/Modules/_io/_iomodule.h @@ -72,7 +72,7 @@ PyObject *filename; /* Not used, but part of the IOError object */ Py_ssize_t written; } PyBlockingIOErrorObject; -PyAPI_DATA(PyObject *) PyExc_BlockingIOError; +extern PyObject *PyExc_BlockingIOError; /* * Offset type for positioning. -- Repository URL: http://hg.python.org/cpython

1 0

cpython (3.2): Issue #14437: Fix building the _io module under Cygwin.
by antoine.pitrou March 31, 2012

March 31, 2012

http://hg.python.org/cpython/rev/f96b603278cc changeset: 76030:f96b603278cc branch: 3.2 parent: 76027:52e32f3b933d user: Antoine Pitrou <solipsis(a)pitrou.net> date: Sat Mar 31 23:50:31 2012 +0200 summary: Issue #14437: Fix building the _io module under Cygwin. files: Misc/NEWS | 2 ++ Modules/_io/_iomodule.h | 2 +- 2 files changed, 3 insertions(+), 1 deletions(-) diff --git a/Misc/NEWS b/Misc/NEWS --- a/Misc/NEWS +++ b/Misc/NEWS @@ -105,6 +105,8 @@ Build ----- +- Issue #14437: Fix building the _io module under Cygwin. + - Issue #14387: Do not include accu.h from Python.h. - Issue #14359: Only use O_CLOEXEC in _posixmodule.c if it is defined. diff --git a/Modules/_io/_iomodule.h b/Modules/_io/_iomodule.h --- a/Modules/_io/_iomodule.h +++ b/Modules/_io/_iomodule.h @@ -67,7 +67,7 @@ PyObject *filename; /* Not used, but part of the IOError object */ Py_ssize_t written; } PyBlockingIOErrorObject; -PyAPI_DATA(PyObject *) PyExc_BlockingIOError; +extern PyObject *PyExc_BlockingIOError; /* * Offset type for positioning. -- Repository URL: http://hg.python.org/cpython

1 0

peps: PEP 412: add missing variables footer and reformat.
by georg.brandl March 31, 2012

March 31, 2012

http://hg.python.org/peps/rev/0dd533ad5967 changeset: 4181:0dd533ad5967 user: Georg Brandl <georg(a)python.org> date: Sat Mar 31 21:40:52 2012 +0200 summary: PEP 412: add missing variables footer and reformat. files: pep-0412.txt | 185 +++++++++++++++++++++----------------- 1 files changed, 101 insertions(+), 84 deletions(-) diff --git a/pep-0412.txt b/pep-0412.txt --- a/pep-0412.txt +++ b/pep-0412.txt @@ -14,26 +14,28 @@ Abstract ======== -This PEP proposes a change in the implementation of the builtin dictionary -type ``dict``. The new implementation allows dictionaries which are used as -attribute dictionaries (the ``__dict__`` attribute of an object) to share -keys with other attribute dictionaries of instances of the same class. +This PEP proposes a change in the implementation of the builtin +dictionary type ``dict``. The new implementation allows dictionaries +which are used as attribute dictionaries (the ``__dict__`` attribute +of an object) to share keys with other attribute dictionaries of +instances of the same class. Motivation ========== -The current dictionary implementation uses more memory than is necessary -when used as a container for object attributes as the keys are -replicated for each instance rather than being shared across many instances -of the same class. -Despite this, the current dictionary implementation is finely tuned and -performs very well as a general-purpose mapping object. +The current dictionary implementation uses more memory than is +necessary when used as a container for object attributes as the keys +are replicated for each instance rather than being shared across many +instances of the same class. Despite this, the current dictionary +implementation is finely tuned and performs very well as a +general-purpose mapping object. -By separating the keys (and hashes) from the values it is possible to share -the keys between multiple dictionaries and improve memory use. -By ensuring that keys are separated from the values only when beneficial, -it is possible to retain the high-performance of the current dictionary -implementation when used as a general-purpose mapping object. +By separating the keys (and hashes) from the values it is possible to +share the keys between multiple dictionaries and improve memory use. +By ensuring that keys are separated from the values only when +beneficial, it is possible to retain the high-performance of the +current dictionary implementation when used as a general-purpose +mapping object. Behaviour ========= @@ -47,76 +49,80 @@ Memory Usage ------------ -Reduction in memory use is directly related to the number of dictionaries -with shared keys in existence at any time. These dictionaries are typically -half the size of the current dictionary implementation. +Reduction in memory use is directly related to the number of +dictionaries with shared keys in existence at any time. These +dictionaries are typically half the size of the current dictionary +implementation. Benchmarking shows that memory use is reduced by 10% to 20% for -object-oriented programs with no significant change in memory use -for other programs. +object-oriented programs with no significant change in memory use for +other programs. Speed ----- -The performance of the new implementation is dominated by memory locality -effects. When keys are not shared (for example in module dictionaries -and dictionary explicitly created by dict() or {} ) then performance is -unchanged (within a percent or two) from the current implementation. +The performance of the new implementation is dominated by memory +locality effects. When keys are not shared (for example in module +dictionaries and dictionary explicitly created by ``dict()`` or +``{}``) then performance is unchanged (within a percent or two) from +the current implementation. -For the shared keys case, the new implementation tends to separate keys -from values, but reduces total memory usage. This will improve performance -in many cases as the effects of reduced memory usage outweigh the loss of -locality, but some programs may show a small slow down. +For the shared keys case, the new implementation tends to separate +keys from values, but reduces total memory usage. This will improve +performance in many cases as the effects of reduced memory usage +outweigh the loss of locality, but some programs may show a small slow +down. Benchmarking shows no significant change of speed for most benchmarks. Object-oriented benchmarks show small speed ups when they create large -numbers of objects of the same class (the gcbench benchmark shows a 10% -speed up; this is likely to be an upper limit). +numbers of objects of the same class (the gcbench benchmark shows a +10% speed up; this is likely to be an upper limit). Implementation ============== -Both the old and new dictionaries consist of a fixed-sized dict struct and -a re-sizeable table. -In the new dictionary the table can be further split into a keys table and -values array. -The keys table holds the keys and hashes and (for non-split tables) the -values as well. It differs only from the original implementation in that it +Both the old and new dictionaries consist of a fixed-sized dict struct +and a re-sizeable table. In the new dictionary the table can be +further split into a keys table and values array. The keys table +holds the keys and hashes and (for non-split tables) the values as +well. It differs only from the original implementation in that it contains a number of fields that were previously in the dict struct. -If a table is split the values in the keys table are ignored, instead the -values are held in a separate array. +If a table is split the values in the keys table are ignored, instead +the values are held in a separate array. Split-Table dictionaries ------------------------ -When dictionaries are created to fill the __dict__ slot of an object, they are -created in split form. The keys table is cached in the type, potentially -allowing all attribute dictionaries of instances of one class to share keys. -In the event of the keys of these dictionaries starting to diverge, -individual dictionaries will lazily convert to the combined-table form. -This ensures good memory use in the common case, and correctness in all cases. +When dictionaries are created to fill the __dict__ slot of an object, +they are created in split form. The keys table is cached in the type, +potentially allowing all attribute dictionaries of instances of one +class to share keys. In the event of the keys of these dictionaries +starting to diverge, individual dictionaries will lazily convert to +the combined-table form. This ensures good memory use in the common +case, and correctness in all cases. When resizing a split dictionary it is converted to a combined table. -If resizing is as a result of storing an instance attribute, and there is -only instance of a class, then the dictionary will be re-split immediately. -Since most OO code will set attributes in the __init__ method, all attributes -will be set before a second instance is created and no more resizing will be -necessary as all further instance dictionaries will have the correct size. -For more complex use patterns, it is impossible to know what is the best -approach, so the implementation allows extra insertions up to the point -of a resize when it reverts to the combined table (non-shared keys). +If resizing is as a result of storing an instance attribute, and there +is only instance of a class, then the dictionary will be re-split +immediately. Since most OO code will set attributes in the __init__ +method, all attributes will be set before a second instance is created +and no more resizing will be necessary as all further instance +dictionaries will have the correct size. For more complex use +patterns, it is impossible to know what is the best approach, so the +implementation allows extra insertions up to the point of a resize +when it reverts to the combined table (non-shared keys). -A deletion from a split dictionary does not change the keys table, it simply -removes the value from the values array. +A deletion from a split dictionary does not change the keys table, it +simply removes the value from the values array. Combined-Table dictionaries --------------------------- -Explicit dictionaries (dict() or {}), module dictionaries and most other -dictionaries are created as combined-table dictionaries. -A combined-table dictionary never becomes a split-table dictionary. -Combined tables are laid out in much the same way as the tables in the old -dictionary, resulting in very similar performance. +Explicit dictionaries (``dict()`` or ``{}``), module dictionaries and +most other dictionaries are created as combined-table dictionaries. A +combined-table dictionary never becomes a split-table dictionary. +Combined tables are laid out in much the same way as the tables in the +old dictionary, resulting in very similar performance. Implementation ============== @@ -129,44 +135,45 @@ Pros ---- -Significant memory savings for object-oriented applications. -Small improvement to speed for programs which create lots of similar objects. +Significant memory savings for object-oriented applications. Small +improvement to speed for programs which create lots of similar +objects. Cons ---- -Change to data structures: -Third party modules which meddle with the internals of the dictionary -implementation will break. -Changes to repr() output and iteration order: -For most cases, this will be unchanged. -However for some split-table dictionaries the iteration order will -change. +Change to data structures: Third party modules which meddle with the +internals of the dictionary implementation will break. -Neither of these cons should be a problem. -Modules which meddle with the internals of the dictionary -implementation are already broken and should be fixed to use the API. -The iteration order of dictionaries was never defined and has always been -arbitrary; it is different for Jython and PyPy. +Changes to repr() output and iteration order: For most cases, this +will be unchanged. However for some split-table dictionaries the +iteration order will change. + +Neither of these cons should be a problem. Modules which meddle with +the internals of the dictionary implementation are already broken and +should be fixed to use the API. The iteration order of dictionaries +was never defined and has always been arbitrary; it is different for +Jython and PyPy. Alternative Implementation -------------------------- -An alternative implementation for split tables, which could save even more -memory, is to store an index in the value field of the keys table (instead -of ignoring the value field). This index would explicitly state where in the -value array to look. The value array would then only require 1 field for each -usable slot in the key table, rather than each slot in the key table. +An alternative implementation for split tables, which could save even +more memory, is to store an index in the value field of the keys table +(instead of ignoring the value field). This index would explicitly +state where in the value array to look. The value array would then +only require 1 field for each usable slot in the key table, rather +than each slot in the key table. This "indexed" version would reduce the size of value array by about -one third. The keys table would need an extra "values_size" field, increasing -the size of combined dicts by one word. -The extra indirection adds more complexity to the code, potentially reducing +one third. The keys table would need an extra "values_size" field, +increasing the size of combined dicts by one word. The extra +indirection adds more complexity to the code, potentially reducing performance a little. -The "indexed" version will not be included in this implementation, -but should be considered deferred rather than rejected, -pending further experimentation. +The "indexed" version will not be included in this implementation, but +should be considered deferred rather than rejected, pending further +experimentation. References ========== @@ -179,3 +186,13 @@ This document has been placed in the public domain. + + +.. + Local Variables: + mode: indented-text + indent-tabs-mode: nil + sentence-end-double-space: t + fill-column: 70 + coding: utf-8 + End: -- Repository URL: http://hg.python.org/peps

1 0

cpython: Fix formatting
by antoine.pitrou March 31, 2012

March 31, 2012

http://hg.python.org/cpython/rev/2f158dbebacf changeset: 76029:2f158dbebacf user: Antoine Pitrou <solipsis(a)pitrou.net> date: Sat Mar 31 21:09:53 2012 +0200 summary: Fix formatting files: Doc/library/signal.rst | 14 +++++++------- 1 files changed, 7 insertions(+), 7 deletions(-) diff --git a/Doc/library/signal.rst b/Doc/library/signal.rst --- a/Doc/library/signal.rst +++ b/Doc/library/signal.rst @@ -238,13 +238,13 @@ The behavior of the call is dependent on the value of *how*, as follows. - * :data:`SIG_BLOCK`: The set of blocked signals is the union of the current - set and the *mask* argument. - * :data:`SIG_UNBLOCK`: The signals in *mask* are removed from the current - set of blocked signals. It is permissible to attempt to unblock a - signal which is not blocked. - * :data:`SIG_SETMASK`: The set of blocked signals is set to the *mask* - argument. + * :data:`SIG_BLOCK`: The set of blocked signals is the union of the current + set and the *mask* argument. + * :data:`SIG_UNBLOCK`: The signals in *mask* are removed from the current + set of blocked signals. It is permissible to attempt to unblock a + signal which is not blocked. + * :data:`SIG_SETMASK`: The set of blocked signals is set to the *mask* + argument. *mask* is a set of signal numbers (e.g. {:const:`signal.SIGINT`, :const:`signal.SIGTERM`}). Use ``range(1, signal.NSIG)`` for a full mask -- Repository URL: http://hg.python.org/cpython

1 0

cpython (3.2): Issue #14456: improve documentation of the signal module w.r.t. threads.
by antoine.pitrou March 31, 2012

March 31, 2012

http://hg.python.org/cpython/rev/52e32f3b933d changeset: 76027:52e32f3b933d branch: 3.2 parent: 76025:0312db5265d0 user: Antoine Pitrou <solipsis(a)pitrou.net> date: Sat Mar 31 20:56:21 2012 +0200 summary: Issue #14456: improve documentation of the signal module w.r.t. threads. files: Doc/library/signal.rst | 78 +++++++++++++++++------------ 1 files changed, 45 insertions(+), 33 deletions(-) diff --git a/Doc/library/signal.rst b/Doc/library/signal.rst --- a/Doc/library/signal.rst +++ b/Doc/library/signal.rst @@ -5,46 +5,58 @@ :synopsis: Set handlers for asynchronous events. -This module provides mechanisms to use signal handlers in Python. Some general -rules for working with signals and their handlers: +This module provides mechanisms to use signal handlers in Python. -* A handler for a particular signal, once set, remains installed until it is - explicitly reset (Python emulates the BSD style interface regardless of the - underlying implementation), with the exception of the handler for - :const:`SIGCHLD`, which follows the underlying implementation. -* There is no way to "block" signals temporarily from critical sections (since - this is not supported by all Unix flavors). +General rules +------------- -* Although Python signal handlers are called asynchronously as far as the Python - user is concerned, they can only occur between the "atomic" instructions of the - Python interpreter. This means that signals arriving during long calculations - implemented purely in C (such as regular expression matches on large bodies of - text) may be delayed for an arbitrary amount of time. +The :func:`signal.signal` function allows to define custom handlers to be +executed when a signal is received. A small number of default handlers are +installed: :const:`SIGPIPE` is ignored (so write errors on pipes and sockets +can be reported as ordinary Python exceptions) and :const:`SIGINT` is +translated into a :exc:`KeyboardInterrupt` exception. -* When a signal arrives during an I/O operation, it is possible that the I/O - operation raises an exception after the signal handler returns. This is - dependent on the underlying Unix system's semantics regarding interrupted system - calls. +A handler for a particular signal, once set, remains installed until it is +explicitly reset (Python emulates the BSD style interface regardless of the +underlying implementation), with the exception of the handler for +:const:`SIGCHLD`, which follows the underlying implementation. -* Because the C signal handler always returns, it makes little sense to catch - synchronous errors like :const:`SIGFPE` or :const:`SIGSEGV`. +There is no way to "block" signals temporarily from critical sections (since +this is not supported by all Unix flavors). -* Python installs a small number of signal handlers by default: :const:`SIGPIPE` - is ignored (so write errors on pipes and sockets can be reported as ordinary - Python exceptions) and :const:`SIGINT` is translated into a - :exc:`KeyboardInterrupt` exception. All of these can be overridden. -* Some care must be taken if both signals and threads are used in the same - program. The fundamental thing to remember in using signals and threads - simultaneously is: always perform :func:`signal` operations in the main thread - of execution. Any thread can perform an :func:`alarm`, :func:`getsignal`, - :func:`pause`, :func:`setitimer` or :func:`getitimer`; only the main thread - can set a new signal handler, and the main thread will be the only one to - receive signals (this is enforced by the Python :mod:`signal` module, even - if the underlying thread implementation supports sending signals to - individual threads). This means that signals can't be used as a means of - inter-thread communication. Use locks instead. +Execution of Python signal handlers +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +A Python signal handler does not get executed inside the low-level (C) signal +handler. Instead, the low-level signal handler sets a flag which tells the +:term:`virtual machine` to execute the corresponding Python signal handler +at a later point(for example at the next :term:`bytecode` instruction). +This has consequences: + +* It makes little sense to catch synchronous errors like :const:`SIGFPE` or + :const:`SIGSEGV`. + +* A long-running calculation implemented purely in C (such as regular + expression matching on a large body of text) may run uninterrupted for an + arbitrary amount of time, regardless of any signals received. The Python + signal handlers will be called when the calculation finishes. + + +Signals and threads +^^^^^^^^^^^^^^^^^^^ + +Python signal handlers are always executed in the main Python thread, +even if the signal was received in another thread. This means that signals +can't be used as a means of inter-thread communication. You can use +the synchronization primitives from the :mod:`threading` module instead. + +Besides, only the main thread is allowed to set a new signal handler. + + +Module contents +--------------- The variables defined in the :mod:`signal` module are: -- Repository URL: http://hg.python.org/cpython

1 0

cpython (merge 3.2 -> default): Issue #14456: improve documentation of the signal module w.r.t. threads.
by antoine.pitrou March 31, 2012

March 31, 2012

http://hg.python.org/cpython/rev/44d13f371811 changeset: 76028:44d13f371811 parent: 76026:2c1432552213 parent: 76027:52e32f3b933d user: Antoine Pitrou <solipsis(a)pitrou.net> date: Sat Mar 31 21:09:00 2012 +0200 summary: Issue #14456: improve documentation of the signal module w.r.t. threads. files: Doc/library/signal.rst | 95 ++++++++++++++++++----------- 1 files changed, 59 insertions(+), 36 deletions(-) diff --git a/Doc/library/signal.rst b/Doc/library/signal.rst --- a/Doc/library/signal.rst +++ b/Doc/library/signal.rst @@ -5,43 +5,61 @@ :synopsis: Set handlers for asynchronous events. -This module provides mechanisms to use signal handlers in Python. Some general -rules for working with signals and their handlers: +This module provides mechanisms to use signal handlers in Python. -* A handler for a particular signal, once set, remains installed until it is - explicitly reset (Python emulates the BSD style interface regardless of the - underlying implementation), with the exception of the handler for - :const:`SIGCHLD`, which follows the underlying implementation. -* Although Python signal handlers are called asynchronously as far as the Python - user is concerned, they can only occur between the "atomic" instructions of the - Python interpreter. This means that signals arriving during long calculations - implemented purely in C (such as regular expression matches on large bodies of - text) may be delayed for an arbitrary amount of time. +General rules +------------- -* When a signal arrives during an I/O operation, it is possible that the I/O - operation raises an exception after the signal handler returns. This is - dependent on the underlying Unix system's semantics regarding interrupted system - calls. +The :func:`signal.signal` function allows to define custom handlers to be +executed when a signal is received. A small number of default handlers are +installed: :const:`SIGPIPE` is ignored (so write errors on pipes and sockets +can be reported as ordinary Python exceptions) and :const:`SIGINT` is +translated into a :exc:`KeyboardInterrupt` exception. -* Because the C signal handler always returns, it makes little sense to catch - synchronous errors like :const:`SIGFPE` or :const:`SIGSEGV`. +A handler for a particular signal, once set, remains installed until it is +explicitly reset (Python emulates the BSD style interface regardless of the +underlying implementation), with the exception of the handler for +:const:`SIGCHLD`, which follows the underlying implementation. -* Python installs a small number of signal handlers by default: :const:`SIGPIPE` - is ignored (so write errors on pipes and sockets can be reported as ordinary - Python exceptions) and :const:`SIGINT` is translated into a - :exc:`KeyboardInterrupt` exception. All of these can be overridden. +There is no way to "block" signals temporarily from critical sections (since +this is not supported by all Unix flavors). -* Some care must be taken if both signals and threads are used in the same - program. The fundamental thing to remember in using signals and threads - simultaneously is: always perform :func:`signal` operations in the main thread - of execution. Any thread can perform an :func:`alarm`, :func:`getsignal`, - :func:`pause`, :func:`setitimer` or :func:`getitimer`; only the main thread - can set a new signal handler, and the main thread will be the only one to - receive signals (this is enforced by the Python :mod:`signal` module, even - if the underlying thread implementation supports sending signals to - individual threads). This means that signals can't be used as a means of - inter-thread communication. Use locks instead. + +Execution of Python signal handlers +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +A Python signal handler does not get executed inside the low-level (C) signal +handler. Instead, the low-level signal handler sets a flag which tells the +:term:`virtual machine` to execute the corresponding Python signal handler +at a later point(for example at the next :term:`bytecode` instruction). +This has consequences: + +* It makes little sense to catch synchronous errors like :const:`SIGFPE` or + :const:`SIGSEGV`. + +* A long-running calculation implemented purely in C (such as regular + expression matching on a large body of text) may run uninterrupted for an + arbitrary amount of time, regardless of any signals received. The Python + signal handlers will be called when the calculation finishes. + + +.. _signals-and-threads: + + +Signals and threads +^^^^^^^^^^^^^^^^^^^ + +Python signal handlers are always executed in the main Python thread, +even if the signal was received in another thread. This means that signals +can't be used as a means of inter-thread communication. You can use +the synchronization primitives from the :mod:`threading` module instead. + +Besides, only the main thread is allowed to set a new signal handler. + + +Module contents +--------------- The variables defined in the :mod:`signal` module are: @@ -189,15 +207,20 @@ .. function:: pthread_kill(thread_id, signum) - Send the signal *signum* to the thread *thread_id*, another thread in the same - process as the caller. The signal is asynchronously directed to thread. + Send the signal *signum* to the thread *thread_id*, another thread in the + same process as the caller. The target thread can be executing any code + (Python or not). However, if the target thread is executing the Python + interpreter, the Python signal handlers will be :ref:`executed by the main + thread <signals-and-threads>`. Therefore, the only point of sending a signal to a particular + Python thread would be to force a running system call to fail with + :exc:`InterruptedError`. Use :func:`threading.get_ident()` or the :attr:`~threading.Thread.ident` - attribute of :attr:`threading.Thread` to get a 'thread identifier' for - *thread_id*. + attribute of :class:`threading.Thread` objects to get a suitable value + for *thread_id*. If *signum* is 0, then no signal is sent, but error checking is still - performed; this can be used to check if a thread is still running. + performed; this can be used to check if the target thread is still running. Availability: Unix (see the man page :manpage:`pthread_kill(3)` for further information). -- Repository URL: http://hg.python.org/cpython

1 0

cpython (merge 3.2 -> default): Issue #14406: Fix a race condition when using
by antoine.pitrou March 31, 2012

March 31, 2012

http://hg.python.org/cpython/rev/2c1432552213 changeset: 76026:2c1432552213 parent: 76024:4805f24ba269 parent: 76025:0312db5265d0 user: Antoine Pitrou <solipsis(a)pitrou.net> date: Sat Mar 31 20:25:22 2012 +0200 summary: Issue #14406: Fix a race condition when using `concurrent.futures.wait(return_when=ALL_COMPLETED)`. Patch by Matt Joiner. files: Lib/concurrent/futures/_base.py | 8 ++++-- Lib/test/test_concurrent_futures.py | 18 ++++++++++++++++- Misc/NEWS | 3 ++ 3 files changed, 25 insertions(+), 4 deletions(-) diff --git a/Lib/concurrent/futures/_base.py b/Lib/concurrent/futures/_base.py --- a/Lib/concurrent/futures/_base.py +++ b/Lib/concurrent/futures/_base.py @@ -111,12 +111,14 @@ def __init__(self, num_pending_calls, stop_on_exception): self.num_pending_calls = num_pending_calls self.stop_on_exception = stop_on_exception + self.lock = threading.Lock() super().__init__() def _decrement_pending_calls(self): - self.num_pending_calls -= 1 - if not self.num_pending_calls: - self.event.set() + with self.lock: + self.num_pending_calls -= 1 + if not self.num_pending_calls: + self.event.set() def add_result(self, future): super().add_result(future) diff --git a/Lib/test/test_concurrent_futures.py b/Lib/test/test_concurrent_futures.py --- a/Lib/test/test_concurrent_futures.py +++ b/Lib/test/test_concurrent_futures.py @@ -183,7 +183,9 @@ for p in processes.values(): p.join() + class WaitTests(unittest.TestCase): + def test_first_completed(self): future1 = self.executor.submit(mul, 21, 2) future2 = self.executor.submit(time.sleep, 1.5) @@ -284,7 +286,21 @@ class ThreadPoolWaitTests(ThreadPoolMixin, WaitTests): - pass + + def test_pending_calls_race(self): + # Issue #14406: multi-threaded race condition when waiting on all + # futures. + event = threading.Event() + def future_func(): + event.wait() + oldswitchinterval = sys.getswitchinterval() + sys.setswitchinterval(1e-6) + try: + fs = {self.executor.submit(future_func) for i in range(100)} + event.set() + futures.wait(fs, return_when=futures.ALL_COMPLETED) + finally: + sys.setswitchinterval(oldswitchinterval) class ProcessPoolWaitTests(ProcessPoolMixin, WaitTests): diff --git a/Misc/NEWS b/Misc/NEWS --- a/Misc/NEWS +++ b/Misc/NEWS @@ -37,6 +37,9 @@ Library ------- +- Issue #14406: Fix a race condition when using ``concurrent.futures.wait( + return_when=ALL_COMPLETED)``. Patch by Matt Joiner. + - Issue #5136: deprecate old, unused functions from tkinter. - Issue #14409: IDLE now properly executes commands in the Shell window -- Repository URL: http://hg.python.org/cpython

1 0

cpython (3.2): Issue #14406: Fix a race condition when using
by antoine.pitrou March 31, 2012

March 31, 2012

http://hg.python.org/cpython/rev/0312db5265d0 changeset: 76025:0312db5265d0 branch: 3.2 parent: 76021:6774a2285579 user: Antoine Pitrou <solipsis(a)pitrou.net> date: Sat Mar 31 20:23:30 2012 +0200 summary: Issue #14406: Fix a race condition when using `concurrent.futures.wait(return_when=ALL_COMPLETED)`. Patch by Matt Joiner. files: Lib/concurrent/futures/_base.py | 8 ++++-- Lib/test/test_concurrent_futures.py | 18 ++++++++++++++++- Misc/NEWS | 3 ++ 3 files changed, 25 insertions(+), 4 deletions(-) diff --git a/Lib/concurrent/futures/_base.py b/Lib/concurrent/futures/_base.py --- a/Lib/concurrent/futures/_base.py +++ b/Lib/concurrent/futures/_base.py @@ -112,12 +112,14 @@ def __init__(self, num_pending_calls, stop_on_exception): self.num_pending_calls = num_pending_calls self.stop_on_exception = stop_on_exception + self.lock = threading.Lock() super().__init__() def _decrement_pending_calls(self): - self.num_pending_calls -= 1 - if not self.num_pending_calls: - self.event.set() + with self.lock: + self.num_pending_calls -= 1 + if not self.num_pending_calls: + self.event.set() def add_result(self, future): super().add_result(future) diff --git a/Lib/test/test_concurrent_futures.py b/Lib/test/test_concurrent_futures.py --- a/Lib/test/test_concurrent_futures.py +++ b/Lib/test/test_concurrent_futures.py @@ -183,7 +183,9 @@ for p in processes: p.join() + class WaitTests(unittest.TestCase): + def test_first_completed(self): future1 = self.executor.submit(mul, 21, 2) future2 = self.executor.submit(time.sleep, 1.5) @@ -284,7 +286,21 @@ class ThreadPoolWaitTests(ThreadPoolMixin, WaitTests): - pass + + def test_pending_calls_race(self): + # Issue #14406: multi-threaded race condition when waiting on all + # futures. + event = threading.Event() + def future_func(): + event.wait() + oldswitchinterval = sys.getswitchinterval() + sys.setswitchinterval(1e-6) + try: + fs = {self.executor.submit(future_func) for i in range(100)} + event.set() + futures.wait(fs, return_when=futures.ALL_COMPLETED) + finally: + sys.setswitchinterval(oldswitchinterval) class ProcessPoolWaitTests(ProcessPoolMixin, WaitTests): diff --git a/Misc/NEWS b/Misc/NEWS --- a/Misc/NEWS +++ b/Misc/NEWS @@ -31,6 +31,9 @@ Library ------- +- Issue #14406: Fix a race condition when using ``concurrent.futures.wait( + return_when=ALL_COMPLETED)``. Patch by Matt Joiner. + - Issue #14409: IDLE now properly executes commands in the Shell window when it cannot read the normal config files on startup and has to use the built-in default key bindings. -- Repository URL: http://hg.python.org/cpython

1 0

cpython (merge default -> default): merge heads
by sandro.tosi March 31, 2012

March 31, 2012

http://hg.python.org/cpython/rev/4805f24ba269 changeset: 76024:4805f24ba269 parent: 76023:40ed19ed0342 parent: 76019:d2b6d821934a user: Sandro Tosi <sandro.tosi(a)gmail.com> date: Sat Mar 31 18:46:45 2012 +0200 summary: merge heads files: Misc/NEWS | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Misc/NEWS b/Misc/NEWS --- a/Misc/NEWS +++ b/Misc/NEWS @@ -37,7 +37,7 @@ Library ------- -- Issue #5136: deprecated old, unused functions from tkinter. +- Issue #5136: deprecate old, unused functions from tkinter. - Issue #14409: IDLE now properly executes commands in the Shell window when it cannot read the normal config files on startup and -- Repository URL: http://hg.python.org/cpython

1 0

cpython (merge default -> default): merge heads
by sandro.tosi March 31, 2012

March 31, 2012

http://hg.python.org/cpython/rev/40ed19ed0342 changeset: 76023:40ed19ed0342 parent: 76022:b926a8c386ad parent: 76018:6023d73c6f87 user: Sandro Tosi <sandro.tosi(a)gmail.com> date: Sat Mar 31 18:44:18 2012 +0200 summary: merge heads files: Misc/NEWS | 2 ++ Modules/_tkinter.c | 19 ++++++++++++++++++- 2 files changed, 20 insertions(+), 1 deletions(-) diff --git a/Misc/NEWS b/Misc/NEWS --- a/Misc/NEWS +++ b/Misc/NEWS @@ -37,6 +37,8 @@ Library ------- +- Issue #5136: deprecated old, unused functions from tkinter. + - Issue #14409: IDLE now properly executes commands in the Shell window when it cannot read the normal config files on startup and has to use the built-in default key bindings. diff --git a/Modules/_tkinter.c b/Modules/_tkinter.c --- a/Modules/_tkinter.c +++ b/Modules/_tkinter.c @@ -1343,6 +1343,11 @@ char *cmd; PyObject *res = NULL; + if (PyErr_WarnEx(PyExc_DeprecationWarning, + "globalcall is deprecated and will be removed in 3.4", + 1) < 0) + return 0; + CHECK_TCL_APPARTMENT; cmd = Merge(args); @@ -1392,6 +1397,11 @@ PyObject *res = NULL; int err; + if (PyErr_WarnEx(PyExc_DeprecationWarning, + "globaleval is deprecated and will be removed in 3.4", + 1) < 0) + return 0; + if (!PyArg_ParseTuple(args, "s:globaleval", &script)) return NULL; @@ -1954,9 +1964,16 @@ static PyObject * Tkapp_Merge(PyObject *self, PyObject *args) { - char *s = Merge(args); + char *s; PyObject *res = NULL; + if (PyErr_WarnEx(PyExc_DeprecationWarning, + "merge is deprecated and will be removed in 3.4", + 1) < 0) + return 0; + + s = Merge(args); + if (s) { res = PyUnicode_FromString(s); ckfree(s); -- Repository URL: http://hg.python.org/cpython

1 0