From: Linus Torvalds <email@example.com> To: Sandeep Patil <firstname.lastname@example.org> Cc: linux-fsdevel <email@example.com>, Linux Kernel Mailing List <firstname.lastname@example.org>, David Howells <email@example.com>, Greg Kroah-Hartman <firstname.lastname@example.org>, stable <email@example.com>, Android Kernel Team <firstname.lastname@example.org> Subject: Re: [PATCH 1/1] fs: pipe: wakeup readers everytime new data written is to pipe Date: Fri, 30 Jul 2021 15:06:00 -0700 [thread overview] Message-ID: <CAHk-=witY33b-vqqp=ApqyoFDpx9p+n4PwG9N-TvF8bq7-tsHw@mail.gmail.com> (raw) In-Reply-To: <email@example.com> On Fri, Jul 30, 2021 at 12:47 PM Sandeep Patil <firstname.lastname@example.org> wrote: > > aren't we supposed to wakeup on each write in level-triggered (default) > case though? No. The thing about level triggered is that if the condition was already true, it would not need a wakeup in the first place. Put another way: select() and poll() are both fundamentally level-triggered. If the condition was already true, they will return success immediately, and don't need any extraneous wakeups. This is literally an epoll() confusion about what an "edge" is. An edge is not "somebody wrote more data". An edge is "there was no data, now there is data". And a level triggered event is *also* not "somebody wrote more data". A level-triggered signal is simply "there is data". Notice how neither edge nor level are about "more data". One is about the edge of "no data" -> "some data", and the other is just a "data is available". Sadly, it seems that our old "we'll wake things up whether needed or not" implementation ended up being something that people thought was edge-triggered semantics. But we have the policy that regressions aren't about documentation or even sane behavior. Regressions are about whether a user application broke in a noticeable way. Linus
next prev parent reply other threads:[~2021-07-30 22:06 UTC|newest] Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-07-29 22:26 [PATCH 0/1] Revert change in pipe reader wakeup behavior Sandeep Patil 2021-07-29 22:26 ` [PATCH 1/1] fs: pipe: wakeup readers everytime new data written is to pipe Sandeep Patil 2021-07-29 23:01 ` Linus Torvalds 2021-07-30 19:11 ` Sandeep Patil 2021-07-30 19:23 ` Linus Torvalds 2021-07-30 19:47 ` Sandeep Patil 2021-07-30 22:06 ` Linus Torvalds [this message] 2021-07-30 22:53 ` Linus Torvalds 2021-07-30 22:55 ` Linus Torvalds 2021-07-31 5:32 ` Greg Kroah-Hartman 2021-08-02 18:59 ` Sandeep Patil
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-=witY33b-vqqp=ApqyoFDpx9p+n4PwG9N-TvF8bq7-tsHw@mail.gmail.com' \ --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: [PATCH 1/1] fs: pipe: wakeup readers everytime new data written is to pipe' \ /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).