environment variable, to provide an opt-in way to protect against denial of
service attacks due to hash collisions within the dict and set types. Patch
by David Malcolm, based on work by Victor Stinner.
Rather than wrapping the C _isdir function in a Python function,
just import the C _isdir function directly. Additionally, add in the
docstring which was left out.
svn+ssh://pythondev@svn.python.org/python/branches/py3k
........
r88111 | antoine.pitrou | 2011-01-19 16:21:35 +0100 (mer., 19 janv. 2011) | 4 lines
Issue #10898: Allow compiling the posix module when the C library defines
a symbol named FSTAT.
........
svn+ssh://pythondev@svn.python.org/python/branches/py3k
........
r87802 | antoine.pitrou | 2011-01-06 19:25:55 +0100 (jeu., 06 janv. 2011) | 6 lines
Issue #7858: Raise an error properly when os.utime() fails under Windows
on an existing file.
(this does not seem to be easily testable)
........
svn+ssh://pythondev@svn.python.org/python/branches/py3k
........
r87666 | amaury.forgeotdarc | 2011-01-03 01:19:11 +0100 (lun., 03 janv. 2011) | 4 lines
#8278: In the Windows implementation of stat() and utime(),
use time_t instead of int. This gives support for dates after 2038,
at least when compiled with VS2003 or later, where time_t is 64bit.
........
svn+ssh://pythondev@svn.python.org/python/branches/py3k
........
r84489 | antoine.pitrou | 2010-09-04 19:21:57 +0200 (sam., 04 sept. 2010) | 4 lines
Issue #7736: Release the GIL around calls to opendir() and closedir()
in the posix module. Patch by Marcin Bachry.
........
svn+ssh://pythondev@svn.python.org/python/branches/py3k
........
r83921 | antoine.pitrou | 2010-08-10 01:39:31 +0200 (mar., 10 août 2010) | 4 lines
Issue #6915: Under Windows, os.listdir() didn't release the Global
Interpreter Lock around all system calls. Original patch by Ryan Kelly.
........
svn+ssh://pythondev@svn.python.org/python/branches/release27-maint
................
r83124 | ronald.oussoren | 2010-07-24 10:46:41 +0100 (Sat, 24 Jul 2010) | 15 lines
Merged revisions 83088 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/branches/py3k
........
r83088 | ronald.oussoren | 2010-07-23 14:53:51 +0100 (Fri, 23 Jul 2010) | 8 lines
This fixes issue7900 by adding code that deals
with the fact that getgroups(2) might return
more that MAX_GROUPS on OSX.
See the issue (and python-dev archives) for the
gory details. Summarized: OSX behaves rather oddly
and Apple says this is intentional.
........
................
svn+ssh://pythondev@svn.python.org/python/branches/py3k
........
r83088 | ronald.oussoren | 2010-07-23 14:53:51 +0100 (Fri, 23 Jul 2010) | 8 lines
This fixes issue7900 by adding code that deals
with the fact that getgroups(2) might return
more that MAX_GROUPS on OSX.
See the issue (and python-dev archives) for the
gory details. Summarized: OSX behaves rather oddly
and Apple says this is intentional.
........
os.kill takes one of two newly added signals, CTRL_C_EVENT and
CTRL_BREAK_EVENT, or any integer value. The events are a special case
which work with subprocess console applications which implement a
special console control handler. Any other value but those two will
cause os.kill to use TerminateProcess, outright killing the process.
This change adds win_console_handler.py, which is a script to implement
SetConsoleCtrlHandler and applicable handler function, using ctypes.
subprocess also gets another attribute which is a necessary flag to
creationflags in Popen in order to send the CTRL events.
svn+ssh://pythondev@svn.python.org/python/trunk
........
r78546 | gregory.p.smith | 2010-02-28 21:43:43 -0800 (Sun, 28 Feb 2010) | 3 lines
Fixes issue #7999: os.setreuid() and os.setregid() would refuse to accept
a -1 parameter on some platforms such as OS X.
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r78527 | gregory.p.smith | 2010-02-28 17:22:39 -0800 (Sun, 28 Feb 2010) | 4 lines
Issue #7242: On Solaris 9 and earlier calling os.fork() from within a
thread could raise an incorrect RuntimeError about not holding the import
lock. The import lock is now reinitialized after fork.
........
r78531 | gregory.p.smith | 2010-02-28 18:31:33 -0800 (Sun, 28 Feb 2010) | 2 lines
Fix for r78527. It left out updating forkpty.
........
- Issue #7714: Use ``gcc -dumpversion`` to detect the version of GCC on
MacOSX.
- Make configure look for util.h as well as libutil.h. The former
is the header file that on OSX contains the defition of openpty.
(Needed to compile for OSX 10.4 on OSX 10.6)
- Use the correct definition of CC to compile the pythonw executable
svn+ssh://pythondev@svn.python.org/python/trunk
........
r74841 | thomas.wouters | 2009-09-16 12:55:54 -0700 (Wed, 16 Sep 2009) | 23 lines
Fix issue #1590864, multiple threads and fork() can cause deadlocks, by
acquiring the import lock around fork() calls. This prevents other threads
from having that lock while the fork happens, and is the recommended way of
dealing with such issues. There are two other locks we care about, the GIL
and the Thread Local Storage lock. The GIL is obviously held when calling
Python functions like os.fork(), and the TLS lock is explicitly reallocated
instead, while also deleting now-orphaned TLS data.
This only fixes calls to os.fork(), not extension modules or embedding
programs calling C's fork() directly. Solving that requires a new set of API
functions, and possibly a rewrite of the Python/thread_*.c mess. Add a
warning explaining the problem to the documentation in the mean time.
This also changes behaviour a little on AIX. Before, AIX (but only AIX) was
getting the import lock reallocated, seemingly to avoid this very same
problem. This is not the right approach, because the import lock is a
re-entrant one, and reallocating would do the wrong thing when forking while
holding the import lock.
Will backport to 2.6, minus the tiny AIX behaviour change.
........
acquiring the import lock around fork() calls. This prevents other threads
from having that lock while the fork happens, and is the recommended way of
dealing with such issues. There are two other locks we care about, the GIL
and the Thread Local Storage lock. The GIL is obviously held when calling
Python functions like os.fork(), and the TLS lock is explicitly reallocated
instead, while also deleting now-orphaned TLS data.
This only fixes calls to os.fork(), not extension modules or embedding
programs calling C's fork() directly. Solving that requires a new set of API
functions, and possibly a rewrite of the Python/thread_*.c mess. Add a
warning explaining the problem to the documentation in the mean time.
This also changes behaviour a little on AIX. Before, AIX (but only AIX) was
getting the import lock reallocated, seemingly to avoid this very same
problem. This is not the right approach, because the import lock is a
re-entrant one, and reallocating would do the wrong thing when forking while
holding the import lock.
Will backport to 2.6, minus the tiny AIX behaviour change.
