linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Davide Libenzi <davidel@xmailserver.org>
To: Jamie Lokier <jamie@shareable.org>
Cc: "David S. Miller" <davem@redhat.com>,
	e0206@foo21.com,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	kuznet@ms2.inr.ac.ru
Subject: Re: [Patch][RFC] epoll and half closed TCP connections
Date: Sun, 13 Jul 2003 16:03:51 -0700 (PDT)	[thread overview]
Message-ID: <Pine.LNX.4.55.0307131542000.15022@bigblue.dev.mcafeelabs.com> (raw)
In-Reply-To: <20030713191559.GA20573@mail.jlokier.co.uk>

On Sun, 13 Jul 2003, Jamie Lokier wrote:

> > After ppl reporting the O_RDONLY|O_TRUNC case I'm inclined to expect
> > everything from existing apps ;) POLLHUP should be returned to apps
> > waiting for POLLOUT while POLLRDHUP to ones for POLLIN.
>
> Not sure exactly how you're thinking with that last sentence.

Brain farting, delete it ;) This is a nice page about POLLHUP treatment :

http://www.greenend.org.uk/rjk/2001/06/poll.html



> At present, it's impossible for socket code to return POLLHUP only to
> apps which are waiting on POLLOUT - because POLLHUP is not maskable in
> sys_poll's API.  Therefore sockets return POLLHUP only if they are
> closed in both directions.
>
> There is no way for a socket to return a HUP condition for someone who
> is waiting only to write, but fortunately that doesn't matter :)

Yes, this could be improved though. If we could only pass our event
interest mask to f_op->poll() the function will be able to register it
inside the wait queue structure and release only waiters that matches the
available condition.



> (*) There aren't that many places which set POLLHUP; they divide into:
> sockets, ttys, SCSI-generic and PPP.  The latter two are not important
> as they don't do half-close.
>
>    __The critical thing with POLL_RDHUP is that it is set if read() would
>    return EOF after returning data.__
>
>    If this condition isn't met, than an app which is using POLL_RDHUP to
>    optimise performance using epoll will hang occasionally.
>
> Sockets are important: TCP is not the only thing to support
> half-closing.  If an app is waiting for POLLRDHUP, and it doesn't know
> what kind of socket it has been given (e.g. AF_UNIX), the network
> stack had better return POLL_RDHUP when there's an EOF pending.
>
> So we'd better add POLLRDHUP to all the socket types which do
> half-closing.  For the rest, no change is required as POLLHUP is
> non-maskable :)  (So apps should always say "if (events &
> (POLLHUP|POLLRDHUP)) check_for_eof()").
>
> And ttys?  They are problematic, because ttys can return EOF _after_
> returning data without closing (and without being hung-up).  An epoll
> loop which is reading a tty (and isn't programmed specially for a tty)
> _must_ receive POLLRDHUP when the EOF is pending, else it may hang.
>
> In other words, POLLRDHUP is the wrong name: the correct name is
> POLLRDEOF.

Please replace 'it may hung' with 'it may hung if it is using the read()
return bytes check trick' ;)



- Davide


  reply	other threads:[~2003-07-13 22:57 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-12 18:16 [Patch][RFC] epoll and half closed TCP connections Eric Varsanyi
2003-07-12 19:44 ` Jamie Lokier
2003-07-12 20:51   ` Eric Varsanyi
2003-07-12 20:48     ` Davide Libenzi
2003-07-12 21:19       ` Eric Varsanyi
2003-07-12 21:20         ` Davide Libenzi
2003-07-12 21:41         ` Davide Libenzi
2003-07-12 23:11           ` Eric Varsanyi
2003-07-12 23:55             ` Davide Libenzi
2003-07-13  1:05               ` Eric Varsanyi
2003-07-13 20:32       ` David Schwartz
2003-07-13 21:10         ` Jamie Lokier
2003-07-13 23:05           ` David Schwartz
2003-07-13 23:09             ` Davide Libenzi
2003-07-14  8:14               ` Alan Cox
2003-07-14 15:03                 ` Davide Libenzi
2003-07-14  1:27             ` Jamie Lokier
2003-07-13 21:14         ` Davide Libenzi
2003-07-13 23:05           ` David Schwartz
2003-07-13 23:11             ` Davide Libenzi
2003-07-13 23:52             ` Entrope
2003-07-14  6:14               ` David Schwartz
2003-07-14  7:20                 ` Jamie Lokier
2003-07-14  1:51             ` Jamie Lokier
2003-07-14  6:14               ` David Schwartz
2003-07-15 20:27             ` James Antill
2003-07-16  1:46               ` David Schwartz
2003-07-16  2:09                 ` James Antill
2003-07-13 13:12     ` Jamie Lokier
2003-07-13 16:55       ` Davide Libenzi
2003-07-12 20:01 ` Davide Libenzi
2003-07-13  5:24   ` David S. Miller
2003-07-13 14:07     ` Jamie Lokier
2003-07-13 17:00       ` Davide Libenzi
2003-07-13 19:15         ` Jamie Lokier
2003-07-13 23:03           ` Davide Libenzi [this message]
2003-07-14  1:41             ` Jamie Lokier
2003-07-14  2:24               ` POLLRDONCE optimisation for epoll users (was: epoll and half closed TCP connections) Jamie Lokier
2003-07-14  2:37                 ` Davide Libenzi
2003-07-14  2:43                   ` Davide Libenzi
2003-07-14  2:56                   ` Jamie Lokier
2003-07-14  3:02                     ` Davide Libenzi
2003-07-14  3:16                       ` Jamie Lokier
2003-07-14  3:21                         ` Davide Libenzi
2003-07-14  3:42                           ` Jamie Lokier
2003-07-14  4:00                             ` Davide Libenzi
2003-07-14  5:51                               ` Jamie Lokier
2003-07-14  6:24                                 ` Davide Libenzi
2003-07-14  6:57                                   ` Jamie Lokier
2003-07-14  3:12                     ` Jamie Lokier
2003-07-14  3:17                       ` Davide Libenzi
2003-07-14  3:35                         ` Jamie Lokier
2003-07-14  3:04                   ` Jamie Lokier
2003-07-14  3:12                     ` Davide Libenzi
2003-07-14  3:27                       ` Jamie Lokier
2003-07-14 17:09     ` [Patch][RFC] epoll and half closed TCP connections kuznet
2003-07-14 17:09       ` Davide Libenzi
2003-07-14 21:45       ` Jamie Lokier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.55.0307131542000.15022@bigblue.dev.mcafeelabs.com \
    --to=davidel@xmailserver.org \
    --cc=davem@redhat.com \
    --cc=e0206@foo21.com \
    --cc=jamie@shareable.org \
    --cc=kuznet@ms2.inr.ac.ru \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).