Subject: Re: 3 questions about the 19990120-accept fix
To: None <firstname.lastname@example.org>
From: Charles M. Hannum <email@example.com>
Date: 01/26/1999 20:08:26
To answer your questions:
1) Technically, returning an error might better. However, the point
here is that servers already don't check for errors. If you change
the definition of blocking accept(2) to make this okay, then you
have to change everything that uses it. If every server has to be
changed, then: a) you're still going to have this problem (at least
with some servers) next year, and b) you might as well have told
them to use non-blocking accept(2)s.
All servers have to already deal with the case of a socket being
closed quickly after it's accept(2)ed; if they don't, then they're
broken in other ways.
(Or, to phrase it another way: Gee, don't you think we considered
2) While it perhaps makes little difference, I considered allowing the
Linux behaviour of returning embryonic connections -- in which case
sofree() would not clean items on so_q0 either. It seemed better
to make the soclose() behaviour symmetric so that this doesn't get
mysteriously broken again in the future. It's certainly not
harmful either way.
3) I think that's true. Another change I was considering was to have
the protocol stack guarantee that the peer information was always
available to accept(2), so that the server always knows who a
connection attempt was made by. This would require some additional
interface changes, though.