[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20070221.224543.95508003.davem@davemloft.net>
Date: Wed, 21 Feb 2007 22:45:43 -0800 (PST)
From: David Miller <davem@...emloft.net>
To: johnpol@....mipt.ru
Cc: shemminger@...ux-foundation.org, netdev@...r.kernel.org
Subject: Re: [Bug 8013] New: select for write hangs on a socket after write
returned ECONNRESET
From: Evgeniy Polyakov <johnpol@....mipt.ru>
Date: Fri, 16 Feb 2007 21:34:27 +0300
> Otherwise we can extend select output mask to include hungup too
> (getting into account that hungup is actually output event).
POLLHUP is non-maskable and this is very clearly defined in
just about every Unix definition of poll().
This non-maskability leads to all the strange semantics in this area.
There is simply no way for sockets to return HUP for someone who
is only waiting to write. Definitions of POLLHUP include language
such as "This event and POLLOUT are mutually exclusive".
I reviewed the current code and the many (and I mean MANY) threads on
this topic that have occurred over the years going back to even 1999,
and what we're doing now is the best possible set of semantics we can
provide without breaking any existing applications.
How many others have gone into the archives and actually looked at
the discussions? That appears to be going out of style :-/
Now, on the read side, for the epoll folks, we added a POLLRDHUP
to handle that case. It's not relevant here, but I'm mentioning it
in passing since it's roughly related and it shows part of the devil
in dealing with POLLHUP semantics.
POLLHUP is a complete mess, because it means different things on
different kinds of fds. And exactly, because it is not maskable,
this makes it totally useless for sockets.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists