Martin Panter added the comment:
IMO closing an OS-level file descriptor in one thread while it is in use by
another thread is a bad idea, full of race conditions and undefined behaviour.
An AttributeError sounds like a best-case scenario. It is like freeing a memory
allocation in one thread
Changes by Ezio Melotti ezio.melo...@gmail.com:
--
nosy: +pitrou
stage: - needs patch
versions: +Python 2.7 -Python 2.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9156
___
Antoine Pitrou added the comment:
I'm not sure there's really a point in making socket.makefile() objects
thread-safe. In any case, making them thread-safe would probably require more
than this small fix.
--
___
Python tracker
Christian Heimes added the comment:
I agree with Antoine. IMHO it's common knowledge that file and socket object
aren't thread safe. All access to these objects must be synced with a lock.
--
nosy: +christian.heimes
___
Python tracker
Mathias Panzenböck added the comment:
The problem is that the other thread is blocked, waiting for new client
connections. A common pattern for very simple server applications (like you
write during exercises at universities) is:
2 threads:
1. A server thread waiting for clients, maybe
Antoine Pitrou added the comment:
2 threads:
1. A server thread waiting for clients, maybe spawning even more
threads for each connection.
2. A small shell thread reading commands from stdin. When quit is
read it closes the server socket, which shuts down the server (the
server thread
Mathias Panzenböck added the comment:
Yeah, I don't remember anymore. It was so long ago.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9156
___
New submission from Mathias Panzenböck grosser.meister.mo...@gmx.net:
When you open a socket._fileobject through sock.makefile('rb') or similar and
you read blocking in one thread and close the file object from another thread
the reading thread gets an AttributeError. This is because the close
