Staging
v0.5.1
https://github.com/python/cpython
Revision 448db2155fc81d2aa84f37dc58683251cba8772e authored by Thomas Wouters on 16 September 2009, 20:06:36 UTC, committed by Thomas Wouters on 16 September 2009, 20:06:36 UTC
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.
........
1 parent c5a6fd7
Raw File
Tip revision: 448db2155fc81d2aa84f37dc58683251cba8772e authored by Thomas Wouters on 16 September 2009, 20:06:36 UTC
Merged revisions 74841 via svnmerge from
Tip revision: 448db21
grammar.mak
# This manages to rebuild graminit.{h, c} under MSVC 6 (Windows), via
#
#     nmake /f grammar.mak
#
# You may also need to copy python23.dll into this directory, or get
# it on your search path.
#
# The intermediate files can be nuked afterwards:
#
#     nmake /f grammar.mak clean
#
# I don't understand the maze of preprocessor #define's on Windows, and
# as a result this requires linking with python23.lib, so it's of no use
# for bootstrapping (the cause appears to be a useless-- in this
# particular case --pragma in PC\pyconfig.h, which demands that
# python23.lib get linked in).

LIBS= ..\PCbuild\python25.lib

CFLAGS= /I ..\Include /I ..\PC /D MS_NO_COREDLL /D PGEN /MD

GRAMMAR_H= ..\Include\graminit.h
GRAMMAR_C= ..\Python\graminit.c
GRAMMAR_INPUT= ..\Grammar\Grammar

PGEN= pgen.exe

POBJS= acceler.obj grammar1.obj listnode.obj node.obj parser.obj \
       parsetok.obj tokenizer.obj bitset.obj metagrammar.obj

PARSER_OBJS= $(POBJS) myreadline.obj

PGOBJS= firstsets.obj grammar.obj pgen.obj printgrammar.obj pgenmain.obj

PGENOBJS= $(POBJS) $(PGOBJS)

$(GRAMMAR_H) $(GRAMMAR_C): $(PGEN) $(GRAMMAR_INPUT)
		$(PGEN) $(GRAMMAR_INPUT) $(GRAMMAR_H) $(GRAMMAR_C)

$(PGEN):	$(PGENOBJS)
		$(CC) $(PGENOBJS) $(LIBS) /Fe$(PGEN)

clean:
        del *.obj
        del $(PGEN)
back to top