Skip Montanaro wrote: > Tim> http://www.python.org/sf/595601 > > Tim> has been in limbo a long time. Looks like it popped up in real > Tim> life, in Zope last week. > > Tim> Quickie: if you let run this long enough, it will die with a > Tim> segfault (and under any version of Python): > > ... > > Isn't this a case of "so don't do that"? I've never encountered this > before, but then I don't close files in one thread while another holds a > reference. > > Would it be reasonable to raise an error or warning if a file's close() > method was called when the reference count was greater than 1? I think it would be very reasonable to raise an error if a file's close() method is called while another thread is executing a system call involving that file. The Python refcount doesn't provide that information, so Jeremy, Tim, Barry, and I have been discussing the idea of maintaining a special refcount on PyFileObjects. The new counter would be incremented before system calls involving f->f_fp and decremented afterward. The counter would provide to the close() method enough information to know it should raise an error instead of closing the file. What we're not sure of is whether we should be concerned about leaking file descriptors due to close() failing. We'd also like some confirmation that fixing this bug is worth a small burden of complexity. Shane P.S. I think this is my First Post on Python-dev. Howdy, all!
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4