[Twisted-Python] Reactors

[Bob Ippolito]

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