bob at redivi.com
Tue Oct 26 13:35:03 EDT 2004
On Oct 26, 2004, at 13:04, James Y Knight wrote:
> On Oct 25, 2004, at 6:02 PM, Bob Ippolito wrote:
>> On Oct 25, 2004, at 17:24, James Y Knight wrote:
>>> Itamar just added half-closing support to Twisted, and I foolishly
>>> volunteered to look at adding support to cfreactor for him. However,
>>> that was before I looked at it. Now that I have, I have little idea
>>> what it's actually doing, so I'm afraid that I'm unable to actually
>>> implement this change.
>>> The "SelectableSocketWrapper" looks like a horrible kludge, and I'm
>>> not sure why it's necessary. Why does it override the wrapped
>>> object's "connectionLost"? Why do you have to wrap&override
>>> Selectable.start/stopReading/Writing, instead of doing that stuff in
>>> reactor.add/removeReader/Writer? What is simulate?? Essentially, I
>>> just don't understand why it is so different from the other
>> The SSW kludge is necessary because it inherits a lot of
>> functionality from the existing default select-based reactor and its
>> sockets. It is a workaround for the lack of extensibility in the
>> implementation of those sockets and that reactor. It could be less
>> hacky if it were inverted, but then you'd have to subclass every
>> possible port and add the reactor notifications, and essentially copy
>> about 80% of twisted.internet.default instead of subclassing it. If
>> you want to refactor it this way, be my guest.. but I'm not bored
>> enough to do it :)
>> The reason for the loseConnection hack is that the existing
>> implementation of loseConnection doesn't do removeReader/Writer!
>> loseConnection effectively kills the socket without notifying the
>> reactor at all. If the existing implementation told the reactor when
>> it was done with a socket, SSW wouldn't be so much of a kludge.
> Er, I don't believe you. If that was the case, it would be a huge fd
> leak, which I'm pretty sure Twisted doesn't have. I removed that hack
> and I don't think anything further broke.
No. It's not a fd leak because loseConnection closes the file
descriptors. It just doesn't tell the reactor it has done so. It
should leak SSW instances (memory) now, though.
> Anyways, I've changed cfreactor to do what I think should be the right
> thing, but it's randomly failing tests. Before my changes it was
> failing a lot of tests too, so I don't know if this is a regression or
I don't really have the time or need to debug this anytime soon. When
I first wrote CFReactor, it passed all of the tests. Either changes in
PyObjC (unlikely) or Twisted (likely) caused these test failures. Some
of it is probably due to tests making incorrect assumptions, especially
because CFReactor isn't designed to be iterated (it has to set up a
timer to stop itself).
More information about the Twisted-Python