[Twisted-Python] Reactors

[James Y Knight]

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