[issue9156] socket._fileobject: read raises AttributeError when closed in another thread

[Martin Panter]

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 while another thread is accessing the memory. What if 
the other thread was slow, or a syscall was interrupted, and hasn’t 
(re-)started the recv() call in time? What if a third thread opens a file and 
reuses the file descriptor you just closed?

I suggest to close this.

--
nosy: +martin.panter
resolution:  -> rejected
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9156] socket._fileobject: read raises AttributeError when closed in another thread

[Ezio Melotti]

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
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9156] socket._fileobject: read raises AttributeError when closed in another thread

[Antoine Pitrou]

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 rep...@bugs.python.org
http://bugs.python.org/issue9156
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9156] socket._fileobject: read raises AttributeError when closed in another thread

[Christian Heimes]

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 rep...@bugs.python.org
http://bugs.python.org/issue9156
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9156] socket._fileobject: read raises AttributeError when closed in another thread

[Mathias Panzenböck]

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 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 just 
notices that the socket was closed and shuts down properly).

This pattern we used all the time when writing exercises in Java. However, it 
seems to work quite differently in Python 3. I have to check if this problem 
still exists.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9156
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9156] socket._fileobject: read raises AttributeError when closed in another thread

[Antoine Pitrou]

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 just notices that the socket was closed and shuts down
 properly).

You're originally talking about socket._fileobject. I don't see what
that has to do with a listening socket being closed (a server thread
waiting for clients).

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9156
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9156] socket._fileobject: read raises AttributeError when closed in another thread

[Mathias Panzenböck]

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
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9156] socket._fileobject: read raises AttributeError when closed in another thread

[Mathias Panzenböck]

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 method 
sets the underlying fileobject._sock member to None and the read/readline/... 
methods call recv on this member without checking if its None. I think the 
_sock member should not be set to None at all but a flag should be set that 
this file object is closed.

For the time being I use the bugfix I attached and therefore do not call 
sock.makefile('rb') but FileObject(sock, 'rb'). FileObject is a subtype of 
socket._fileobject that overrides the close method and closed property.

I don't know if this bug persists in 2.7 or 3.x. I still use Fedora 12 and that 
comes with Python 2.6.2.

--
components: Library (Lib)
files: FileObject.py
messages: 109281
nosy: panzi
priority: normal
severity: normal
status: open
title: socket._fileobject: read raises AttributeError when closed in another 
thread
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file17860/FileObject.py

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9156
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com