From: Linus Torvalds <firstname.lastname@example.org> To: "Michael Kerrisk (man-pages)" <email@example.com> Cc: Alexander Viro <firstname.lastname@example.org>, David Howells <email@example.com>, Rasmus Villemoes <firstname.lastname@example.org>, Greg Kroah-Hartman <email@example.com>, Peter Zijlstra <firstname.lastname@example.org>, Nicolas Dichtel <email@example.com>, Ian Kent <firstname.lastname@example.org>, Christian Brauner <email@example.com>, firstname.lastname@example.org, "email@example.com" <firstname.lastname@example.org>, Linux API <email@example.com>, lkml <firstname.lastname@example.org>, Davide Libenzi <email@example.com> Subject: Re: Regression: epoll edge-triggered (EPOLLET) for pipes/FIFOs Date: Mon, 12 Oct 2020 15:30:08 -0700 [thread overview] Message-ID: <CAHk-=wjYN_80i=9ALMwxZ77_TS_TMjkVyZ261xtuiMUaZsM4ng@mail.gmail.com> (raw) In-Reply-To: <firstname.lastname@example.org> On Mon, Oct 12, 2020 at 1:30 PM Michael Kerrisk (man-pages) <email@example.com> wrote: > > I don't think this is correct. The epoll(7) manual page > sill carries the text written long ago by Davide Libenzi, > the creator of epoll: > > Since even with edge-triggered epoll, multiple events can be gen‐ > erated upon receipt of multiple chunks of data, the caller has the > option to specify the EPOLLONESHOT flag, to tell epoll to disable > the associated file descriptor after the receipt of an event with > epoll_wait(2). Hmm. The more I read that paragraph, the more I think the epoll man-page really talks about something that _could_ happen due to internal implementation details, but that isn't really something an epoll user would _want_ to happen or depend on. IOW, in that whole "even with edge-triggered epoll, multiple events can be generated", I'd emphasize the *can* part (as in "might", not as in "will"), and my reading is that the reason EPOLLONESHOT flag exists is to avoid that whole "this is implementation-defined, and if you absolutely _must_ get just a single event, you need to use EPOLLONESHOT to make sure you remove yourself after you got the one single event you waited for". The corollary of that reading is that the new pipe behavior is actually the _expected_ one, and the old pipe behavior where we would generate multiple events is the unwanted implementation detail of "this might still happen, and if you care, you will need to do extra stuff". Anyway, I don't absolutely hate that patch of mine, but it does seem nonsensical and pointless, and I think I'll just hold off on applying it until we hear of something actually breaking. Which I suspect simply won't happen. Getting two epoll notifications when the pipe state didn't really change in between is not something I can see anybody really depending on. You _will_ get the second notification if somebody actually emptied the pipe in between, and you have a real new "edge". But hey, I am continually surprised by what user space code then occasionally does, despite my fairly low expectations. Linus
next prev parent reply other threads:[~2020-10-12 22:30 UTC|newest] Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-10-12 18:39 Michael Kerrisk (man-pages) 2020-10-12 19:25 ` Linus Torvalds 2020-10-12 19:28 ` Linus Torvalds 2020-10-12 20:30 ` Michael Kerrisk (man-pages) 2020-10-12 20:52 ` Linus Torvalds 2020-10-12 21:43 ` Randy Dunlap 2020-10-12 21:51 ` Michael Kerrisk (man-pages) 2020-10-12 22:30 ` Linus Torvalds [this message] 2020-10-13 9:47 ` Michael Kerrisk (man-pages)
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='CAHk-=wjYN_80i=9ALMwxZ77_TS_TMjkVyZ261xtuiMUaZsM4ng@mail.gmail.com' \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: Regression: epoll edge-triggered (EPOLLET) for pipes/FIFOs' \ /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
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).