[Twisted-Python] Reactors
Bob Ippolito
bob at redivi.com
Thu Nov 18 18:29:47 EST 2004
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
More information about the Twisted-Python
mailing list