On Tue, Apr 1, 2008 at 5:09 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> This is not something that keeps me awake at night, but I am aware of > it. Your solution (a counter) seems fine except I think perhaps the > close() call should not raise IOError -- instead, it should set a flag > so that the thread that makes the counter go to zero can close the > thread (after all the file got closed while it was being used). > No, raising IOError is the right thing to do here. The problem is that calling close on a file implies that the close actually completed in the OS when it returns. The call should not return until the file object has actually been closed in the underlying layers. You can't leave it for later to be done by one of the other currently operating threads as you violate the close semantics and lose direct indication of an error that occurred during close. > There are of course other concurrency issues besides close -- what if > two threads both try to do I/O on the file? What will the C stdio > library do in that case? Are stdio files thread-safe at the C level? > So (classically contradicting myself while I think the problem over > more) perhaps any I/O operation should be disallowed while the file is > in use by another thread? > that does sound like the safest thing to do... -gps
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
