On Nov 18, 2004, at 9:55 PM, James Y Knight wrote:
On Nov 18, 2004, at 3:58 AM, Bob Ippolito wrote:
The problem is that the classes that use file descriptors make certain assumptions that are only true for the default (and probably poll) reactors. Particularly, from memory, they don't have to tell the reactor when they want to lose connection, and they do something very crazy in order to determine when a TCP connection is established. In the case of cfreactor, a wrapper object needs to live on top of the sockets so that the reactor will wake up on activity, and without proper notifications these objects can't be disposed of.
Okay, I'm still unsure why this is necessary. Right now, the reactors just get told when it should send notifications for a socket being readable or writable. When a socket is closed, the reactor is told stopReading/stopWriting. For all other reactors, that causes all reactorstate associated with the socket to be disposed of. They just know the user no longer wants to see notifications, for whatever reason. That the reason is the socket closed doesn't matter. Why does the CF reactor have to care? And, if it _really does_, would it not be good enough to use a weakref to the Selectable with a callback?
It also calls (or at least used to call) stopReading and stopWriting immediately after a TCP client connection is made, and then calls startReading and startWriting again.. which causes the wrapper to get thrown away, so it might miss notifications in the meantime. I think it already uses weakrefs, but I was never confident that they would go away at the right time, and from recent python-dev threads, it doesn't sound like it's a good thing to depend on at all any time soon :) -bob