| 
									
										
										
										
											1994-05-16 09:35:22 +00:00
										 |  |  | # The following self-contained little program usually freezes with most | 
					
						
							|  |  |  | # threads reporting | 
					
						
							| 
									
										
										
										
											2001-01-21 07:07:30 +00:00
										 |  |  | # | 
					
						
							| 
									
										
										
										
											1994-05-16 09:35:22 +00:00
										 |  |  | # Unhandled exception in thread: | 
					
						
							|  |  |  | # Traceback (innermost last): | 
					
						
							|  |  |  | #   File "importbug.py", line 6 | 
					
						
							|  |  |  | #     x = whrandom.randint(1,3) | 
					
						
							|  |  |  | # AttributeError: randint | 
					
						
							| 
									
										
										
										
											2001-01-21 07:07:30 +00:00
										 |  |  | # | 
					
						
							| 
									
										
										
										
											1994-05-16 09:35:22 +00:00
										 |  |  | # Here's the program; it doesn't use anything from the attached module: | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | import thread | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | def task(): | 
					
						
							|  |  |  |     global N | 
					
						
							|  |  |  |     import whrandom | 
					
						
							|  |  |  |     x = whrandom.randint(1,3) | 
					
						
							|  |  |  |     a.acquire() | 
					
						
							|  |  |  |     N = N - 1 | 
					
						
							|  |  |  |     if N == 0: done.release() | 
					
						
							|  |  |  |     a.release() | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | a = thread.allocate_lock() | 
					
						
							|  |  |  | done = thread.allocate_lock() | 
					
						
							|  |  |  | N = 10 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | done.acquire() | 
					
						
							|  |  |  | for i in range(N): | 
					
						
							|  |  |  |     thread.start_new_thread(task, ()) | 
					
						
							|  |  |  | done.acquire() | 
					
						
							|  |  |  | print 'done' | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | # Sticking an acquire/release pair around the 'import' statement makes the | 
					
						
							|  |  |  | # problem go away. | 
					
						
							| 
									
										
										
										
											2001-01-21 07:07:30 +00:00
										 |  |  | # | 
					
						
							| 
									
										
										
										
											1994-05-16 09:35:22 +00:00
										 |  |  | # I believe that what happens is: | 
					
						
							| 
									
										
										
										
											2001-01-21 07:07:30 +00:00
										 |  |  | # | 
					
						
							| 
									
										
										
										
											1994-05-16 09:35:22 +00:00
										 |  |  | # 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 | 
					
						
							| 
									
										
										
										
											2001-01-21 07:07:30 +00:00
										 |  |  | # | 
					
						
							| 
									
										
										
										
											1994-05-16 09:35:22 +00:00
										 |  |  | #         v = eval_code(co, d, d, d, (object *)NULL); | 
					
						
							| 
									
										
										
										
											2001-01-21 07:07:30 +00:00
										 |  |  | # | 
					
						
							| 
									
										
										
										
											1994-05-16 09:35:22 +00:00
										 |  |  | #    to initialize the module. | 
					
						
							| 
									
										
										
										
											2001-01-21 07:07:30 +00:00
										 |  |  | # | 
					
						
							| 
									
										
										
										
											1994-05-16 09:35:22 +00:00
										 |  |  | # 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. | 
					
						
							| 
									
										
										
										
											2001-01-21 07:07:30 +00:00
										 |  |  | # | 
					
						
							| 
									
										
										
										
											1994-05-16 09:35:22 +00:00
										 |  |  | # 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. | 
					
						
							| 
									
										
										
										
											2001-01-21 07:07:30 +00:00
										 |  |  | # | 
					
						
							| 
									
										
										
										
											1994-05-16 09:35:22 +00:00
										 |  |  | # 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. | 
					
						
							| 
									
										
										
										
											2001-01-21 07:07:30 +00:00
										 |  |  | # | 
					
						
							| 
									
										
										
										
											1994-05-16 09:35:22 +00:00
										 |  |  | # 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 | 
					
						
							|  |  |  | # giving up interpreter_lock, and have IMPORT_NAME set it & restore (plain | 
					
						
							|  |  |  | # clearing would not work) it around its call to import_module.  To its | 
					
						
							|  |  |  | # credit, there's something wonderfully perverse about fixing a race via an | 
					
						
							|  |  |  | # unprotected static <grin>. | 
					
						
							| 
									
										
										
										
											2001-01-21 07:07:30 +00:00
										 |  |  | # | 
					
						
							| 
									
										
										
										
											1994-05-16 09:35:22 +00:00
										 |  |  | # as-with-most-other-things-(pseudo-)parallel-programming's-more-fun- | 
					
						
							|  |  |  | #    in-python-too!-ly y'rs  - tim | 
					
						
							| 
									
										
										
										
											2001-01-21 07:07:30 +00:00
										 |  |  | # | 
					
						
							| 
									
										
										
										
											1994-05-16 09:35:22 +00:00
										 |  |  | # Tim Peters   tim@ksr.com | 
					
						
							|  |  |  | # not speaking for Kendall Square Research Corp |