summaryrefslogtreecommitdiffstats
path: root/Lib
diff options
context:
space:
mode:
authorArmin Rigo <arigo@tunes.org>2007-10-21 09:14:15 (GMT)
committerArmin Rigo <arigo@tunes.org>2007-10-21 09:14:15 (GMT)
commit148618245167e56ac4b9075881f2b790078c1cbc (patch)
tree836b502bb2adfff08b8b3a581fd4c6a2002d576f /Lib
parent27a4498fcafad471d158f094d5be914e8884a7d2 (diff)
downloadcpython-148618245167e56ac4b9075881f2b790078c1cbc.zip
cpython-148618245167e56ac4b9075881f2b790078c1cbc.tar.gz
cpython-148618245167e56ac4b9075881f2b790078c1cbc.tar.bz2
Add a crasher for the long-standing issue with closing a file
while another thread uses it.
Diffstat (limited to 'Lib')
-rw-r--r--Lib/test/crashers/multithreaded_close.py14
1 files changed, 14 insertions, 0 deletions
diff --git a/Lib/test/crashers/multithreaded_close.py b/Lib/test/crashers/multithreaded_close.py
new file mode 100644
index 0000000..5224341
--- /dev/null
+++ b/Lib/test/crashers/multithreaded_close.py
@@ -0,0 +1,14 @@
+# 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()