Yes, this is because of the (unfortunate) availability of the dup() operation. Originally, dup() was only available on Unix, where it's implemented in the kernel at the file descriptor level: when several file descriptors all share the same underlying socket, the socket isn't really closed until the last of those file descriptors are closed, essentially implementing reference counting for file descriptors. When it was deemed that this (only occasionally useful) feature be made available on Windows, which doesn't support this functionality at the socket descriptor level (perhaps it supports it at some other level, but I wasn't a Windows wizard -- and still am not :-), I implemented this by implementing the dup() operation in Python objects, depending on Python's reference counting to close the single underlying _socket object when the last Python-level socket object is closed.
So, unfortunately, in IronPython, you'll have to implement reference counting for socket object somehow. Sorry, --Guido On 6/12/06, Bruce Christensen <[EMAIL PROTECTED]> wrote: > In implementing the IronPython _socket module, I've discovered some > puzzling behavior in the standard Python socket wrapper module: > socket._socketobject.close() doesn't actually close sockets; rather, it > just sets _sock to an instance of _closedsocket and lets the GC clean up > the real socket. (See socket.py around line 160.) > > This works fine with a reference counting GC, but can potentially leave > sockets hanging around for a long time on platforms (e.g. the CLR) with > other GC algorithms. It causes most of the socket unit tests to fail on > IronPython. > > Is there a reason for this implementation? > > This patch to _socketobject.close() makes socket.py work with > IronPython: > > def close(self): > + if not isinstance(self._sock, _closedsocket): > + self._sock.close() > self._sock = _closedsocket() > self.send = self.recv = self.sendto = self.recvfrom = > self._sock._dummy > > --Bruce > _______________________________________________ > 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/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ 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
