[Python-Dev] Thread-safe file objects, the return

[Gregory P. Smith]

On Tue, Apr 1, 2008 at 5:09 PM, Guido van Rossum <guido at python.org> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20080401/908e21e2/attachment-0001.htm