summaryrefslogtreecommitdiffstats
path: root/Lib/test/crashers/multithreaded_close.py
diff options
context:
space:
mode:
authorBenjamin Peterson <benjamin@python.org>2009-03-29 21:22:35 (GMT)
committerBenjamin Peterson <benjamin@python.org>2009-03-29 21:22:35 (GMT)
commitd2c184605e78d9eaf18a6ce83e4ac922bdd18057 (patch)
treee906a0b0a3c2695809c50d9aa7069fca45d1bb82 /Lib/test/crashers/multithreaded_close.py
parentb006fcc30ce0277e5fa45fbab059cc7d3154bbcc (diff)
downloadcpython-d2c184605e78d9eaf18a6ce83e4ac922bdd18057.zip
cpython-d2c184605e78d9eaf18a6ce83e4ac922bdd18057.tar.gz
cpython-d2c184605e78d9eaf18a6ce83e4ac922bdd18057.tar.bz2
this has been fixed since 2.6 (I love removing these)
Diffstat (limited to 'Lib/test/crashers/multithreaded_close.py')
-rw-r--r--Lib/test/crashers/multithreaded_close.py14
1 files changed, 0 insertions, 14 deletions
diff --git a/Lib/test/crashers/multithreaded_close.py b/Lib/test/crashers/multithreaded_close.py
deleted file mode 100644
index 5224341..0000000
--- a/Lib/test/crashers/multithreaded_close.py
+++ /dev/null
@@ -1,14 +0,0 @@
-# f.close() is not thread-safe: calling it at the same time as another
-# operation (or another close) on the same file, but done from another
-# thread, causes crashes. The issue is more complicated than it seems,
-# witness the discussions in:
-#
-# http://bugs.python.org/issue595601
-# http://bugs.python.org/issue815646
-
-import thread
-
-while 1:
- f = open("multithreaded_close.tmp", "w")
- thread.start_new_thread(f.close, ())
- f.close()