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? QTReactor seems to have a similar architecture, with objects that live on top of sockets, but it doesn't have the same crazy hacks. Of course, since it's also failing tests, I don't know if it's necessarily a good thing to point at. ;) James