[Python-checkins] CVS: python/dist/src/Demo/threads bug.py,1.1,1.2

Tim Peters tim_one@users.sourceforge.net
Sat, 20 Jan 2001 23:06:23 -0800


Update of /cvsroot/python/python/dist/src/Demo/threads
In directory usw-pr-cvs1:/tmp/cvs-serv29956

Modified Files:
	bug.py 
Log Message:
Whitespace normalization.


Index: bug.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Demo/threads/bug.py,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -r1.1 -r1.2
*** bug.py	1994/05/16 09:35:22	1.1
--- bug.py	2001/01/21 07:06:21	1.2
***************
*** 1,5 ****
  # The following self-contained little program usually freezes with most
  # threads reporting
! # 
  # Unhandled exception in thread:
  # Traceback (innermost last):
--- 1,5 ----
  # The following self-contained little program usually freezes with most
  # threads reporting
! #
  # Unhandled exception in thread:
  # Traceback (innermost last):
***************
*** 7,11 ****
  #     x = whrandom.randint(1,3)
  # AttributeError: randint
! # 
  # Here's the program; it doesn't use anything from the attached module:
  
--- 7,11 ----
  #     x = whrandom.randint(1,3)
  # AttributeError: randint
! #
  # Here's the program; it doesn't use anything from the attached module:
  
***************
*** 34,59 ****
  # Sticking an acquire/release pair around the 'import' statement makes the
  # problem go away.
! # 
  # I believe that what happens is:
! # 
  # 1) The first thread to hit the import atomically reaches, and executes
  #    most of, get_module.  In particular, it finds Lib/whrandom.pyc,
  #    installs its name in sys.modules, and executes
! # 
  #         v = eval_code(co, d, d, d, (object *)NULL);
! # 
  #    to initialize the module.
! # 
  # 2) eval_code "ticker"-slices the 1st thread out, and gives another thread
  #    a chance.  When this 2nd thread hits the same 'import', import_module
  #    finds 'whrandom' in sys.modules, so just proceeds.
! # 
  # 3) But the 1st thread is still "in the middle" of executing whrandom.pyc.
  #    So the 2nd thread has a good chance of trying to look up 'randint'
  #    before the 1st thread has placed it in whrandom's dict.
! # 
  # 4) The more threads there are, the more likely that at least one of them
  #    will do this before the 1st thread finishes the import work.
! # 
  # If that's right, a perhaps not-too-bad workaround would be to introduce a
  # static "you can't interrupt this thread" flag in ceval.c, check it before
--- 34,59 ----
  # Sticking an acquire/release pair around the 'import' statement makes the
  # problem go away.
! #
  # I believe that what happens is:
! #
  # 1) The first thread to hit the import atomically reaches, and executes
  #    most of, get_module.  In particular, it finds Lib/whrandom.pyc,
  #    installs its name in sys.modules, and executes
! #
  #         v = eval_code(co, d, d, d, (object *)NULL);
! #
  #    to initialize the module.
! #
  # 2) eval_code "ticker"-slices the 1st thread out, and gives another thread
  #    a chance.  When this 2nd thread hits the same 'import', import_module
  #    finds 'whrandom' in sys.modules, so just proceeds.
! #
  # 3) But the 1st thread is still "in the middle" of executing whrandom.pyc.
  #    So the 2nd thread has a good chance of trying to look up 'randint'
  #    before the 1st thread has placed it in whrandom's dict.
! #
  # 4) The more threads there are, the more likely that at least one of them
  #    will do this before the 1st thread finishes the import work.
! #
  # If that's right, a perhaps not-too-bad workaround would be to introduce a
  # static "you can't interrupt this thread" flag in ceval.c, check it before
***************
*** 62,69 ****
  # credit, there's something wonderfully perverse about fixing a race via an
  # unprotected static <grin>.
! # 
  # as-with-most-other-things-(pseudo-)parallel-programming's-more-fun-
  #    in-python-too!-ly y'rs  - tim
! # 
  # Tim Peters   tim@ksr.com
  # not speaking for Kendall Square Research Corp
--- 62,69 ----
  # credit, there's something wonderfully perverse about fixing a race via an
  # unprotected static <grin>.
! #
  # as-with-most-other-things-(pseudo-)parallel-programming's-more-fun-
  #    in-python-too!-ly y'rs  - tim
! #
  # Tim Peters   tim@ksr.com
  # not speaking for Kendall Square Research Corp