On 07:24 pm, rich@noir.com wrote:
I don't think so. I believe the reactor is actually added during the import. (I learned this as I discovered that reactors can't be restarted, which means you have to manually create a new one as a fixture for simple unittest work.)
I looked through the code and there's a call in the reactor to fileno immediately after the call to doRead. It seems to be attempting to check for file descriptors which broke during the read, but I think that's a mistake. (Or at least, I'm confused about how else to do it). Seems to me that the only time my object has control in order to remove itself is during doRead. So I'm thinking that either...
a) there's some other way to close out my object that I just haven't discovered or
b) the code which checks the file descriptor, (which may have been closed), after doRead is doing so mistakenly.
For now, in my real code, I'm just leaving the file descriptor. But I'd like to know how this is intended to be used.
It isn't `doRead`'s job to close the file descriptor. At most, it's `doRead`'s job to signal that the descriptor is no longer worth keeping open by returning something like an instance of ConnectionDone or ConnectionLost. Then the reactor will call connectionLost on your object and you can close the file descriptor there. The documentation for how this all works could probably be improved. Once you figure it out, would you mind submitting a patch? Also, you won't accomplish much by adding a file descriptor for a normal file to the reactor. Select, poll, etc, will always indicate that such descriptors are both readable and writeable. Jean-Paul