[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wiT67DtHF8dSu8nJpA7h+T4jBxfAuR7rcp0iLpKfvF=tw@mail.gmail.com>
Date: Sat, 10 Dec 2022 11:26:16 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Jens Axboe <axboe@...nel.dk>
Cc: netdev <netdev@...r.kernel.org>,
"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>
Subject: Re: [GIT PULL] Add support for epoll min wait time
On Sat, Dec 10, 2022 at 10:51 AM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> Now, maybe there is some reason why the tty like VMIN/VTIME just isn't
> relevant, but I do think that people have successfully used VMIN/VTIME
> for long enough that it should be at least given some thought.
Side note: another thing the tty layer model does is to make this be a
per-tty thing.
That's actually noticeable in regular 'poll()/select()' usage, so it
has interesting semantics: if VTIME is 0 (ie there is no inter-event
timeout), then poll/select will return "readable" only once you hit
VMIN characters.
Maybe this isn't relevant for the epoll() situation, but it might be
worth thinking about.
It's most definitely not obvious that any epoll() timeout should be
the same for different file descriptors.
Willy already mentioned "urgent file descriptors", and making these
things be per-fd would very naturally solve that whole situation too.
Again: I don't want to in any way force a "tty-like" solution. I'm
just saying that this kind of thing does have a long history, and I do
get the feeling that the tty solution is the more flexible one.
And while the tty model is "per tty" (it's obviously hidden in the
termios structure), any epoll equivalent would have to be different
(presumably per-event or something).
So I'm also not advocating some 1:1 equivalence, just bringing up the
whole "ttys do this similar thing but they seem to have a more
flexible model".
Linus
Powered by blists - more mailing lists