homepage

Note: This may be a dupe or a generalization of 595601.
Running below code snippet on 2.3.1 release and debug 
build on Windows 2000/XP a few times will inevitably lead 
to a crash. 2.2.2 also exhibits this behavior.
The crashing code:
------------
import thread
f=open("tmp1", "w")
def worker():
 global f
 while 1:
 f.close()
 f=open("tmp1", "w")
 f.seek (0, 0)
thread.start_new_thread(worker, ())
thread.start_new_thread(worker, ())
while 1: pass
-------------
The issue appears to be this (and similar) code sections 
from fileobject.c:
	Py_BEGIN_ALLOW_THREADS
	errno = 0;
	ret = _portable_fseek(f->f_fp, offset, whence);
	Py_END_ALLOW_THREADS
Note that due to 
Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS, 
f->f_fp can be set to NULL by file_close prior to entering 
_portable_fseek. Similar crashes can be observed with 
read, write and close itself when they are mixed with a 
concurrent close.
Obviously, the offending python code is buggy and a lock 
should be used to prevent concurrent access to f. 
However, it seems unreasonable for Python to crash 
because of it.
A mutex preventing concurrent access to the file object 
seems like a reasonable way to fix this.