Comment 11 for bug 824797

Revision history for this message
Andrew Bennetts (spiv) wrote : Re: [Bug 824797] Re: bzr serve doesn't drop idle/dead connections

On Fri, Sep 16, 2011 at 03:53:08PM +0200, John Arbash Meinel wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 9/16/2011 2:16 AM, Andrew Bennetts wrote:
> > On Tue, Sep 13, 2011 at 12:31:29PM -0000, John A Meinel wrote:
> >> (If you do select.select([r], [], []) and the far side of r has
> >> been closed, would select hang forever?, maybe I need to pass it
> >> in the last list as well.)
> >
> > Beware Windows (and diverse platforms in general): the third
> > argument to select has a subtly different meaning there. I forget
> > the exact details, just that Linux tends to use the exceptfds set
> > for fewer things (e.g. when a TCP URG bit was received?), and
> > Windows tends to signal some connection errors there as well.
> >
> > Basically, be extra sure to test on both Windows and Linux :)
> >
>
> So, I can understand the desire to pass the file descriptor to
> 'errors'. But what do you actually *do* if it returns something there:
>
> rs, _, xs = select.select([fd], [], [fd], timeout)
>
> if xs:
> ????
>
> Do I:
>
> 1) Ignore xs, but assume that it makes it more likely that select()
> will raise an exception?

I don't understand why you'd expect more exceptions to be raised in this
case.

> 2) Treat xs having a file descriptor as meaning the client has timed
> out, and thus we should just clean up and go home?

I don't think that's a good assumption.

> 3) Try to do something like read on the descriptor in order to figure
> out what is actually wrong with it?

That's a reasonable approach.

With either 1 or 3, the difference vs. not passing any fds to the 3rd
arg is that there are fewer cases where select will hang until the
timeout. Precisely which cases those are varies by platform,
unfortunately.

[…]
> Now maybe select(, , errfds) is very implementation specific. I don't
> have any problem using it, but I have no idea what to *do* with the
> results.

It is, as I mentioned in my original mail. e.g. IIRC a failure of a
connect(2) is signalled via exceptfds on Windows but not on Linux.

As for what to do with it: I was responding to your concern that select
might “hang forever” in some cases. If you want select to wake up when
any event happens on a fd, then you need to ask select to notify you of
all events. I haven't taken the time to get familiar with this
particular case, so it's certainly possible that just passing reader_fds
is sufficient. But if you're not sure, I'd err on the side of caution,
because hangs are a very frustrating failure mode.

You could also try looking at Twisted's selectreactor to see how it
interprets the result of select in general and w.r.t. to specific
platforms.

-Andrew.