The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Warner Losh <imp@bsdimp.com>
To: Peter Jeremy <peter@rulingia.com>
Cc: The Eunuchs Hysterical Society <tuhs@tuhs.org>
Subject: Re: [TUHS] non-blocking IO
Date: Thu, 4 Jun 2020 08:19:58 -0600	[thread overview]
Message-ID: <CANCZdfo289SQhA3tu5Z=RsDv3VrxgZ00r3M7mPNPCMEQiMvuQA@mail.gmail.com> (raw)
In-Reply-To: <20200604090436.GJ279@server.rulingia.com>

[-- Attachment #1: Type: text/plain, Size: 3065 bytes --]

On Thu, Jun 4, 2020 at 3:06 AM Peter Jeremy <peter@rulingia.com> wrote:

> On 2020-Jun-01 07:58:02 -0700, Larry McVoy <lm@mcvoy.com> wrote:
> >On Mon, Jun 01, 2020 at 01:32:56PM +1000, Dave Horsfall wrote:
> >> On Mon, 1 Jun 2020, Rob Pike wrote:
> >>
> >> > I???m not quite sure why the Research lineage did not include
> >> > non-blocking behaviour, especially in view of the man page comments.
> >> > Maybe it was seen as against the Unix philosophy, with select()
> >> > offering sufficient mechanism to avoid blocking (with open() the hard
> >> > corner case)?
> >> >
> >> >That's it. Select was good enough for our purposes.
> >>
> >> After being dragged through both Berserkley and SysVile, I never did
> get the
> >> hang of poll()/select() etc,,,
> >
> >I'm sure you could, select is super handy, think a network server like
> >apache.
>
> My view may be unpopular but I've always been disappointed that Unix
> implemented blocking I/O only and then had to add various hacks to cover
> up for the lack of asynchonous I/O.  It's trivial to build blocking I/O
> operations on top of asynchonous I/O operations.  It's impossible to do
> the opposite without additional functionality.
>
> I also found it disappointing that poll()/select() only worked on TTY and
> network operations.  HDDs are really slow compared to CPUs and it would be
> really nice if a process could go and do something else whilst waiting for
> a file to open.
>

Lest anybody think this is a theoretical concern, Netflix has spent quite a
bit of effort to reduce the sources of latency in our system. The latency
for open doesn't happen often, due to caching, but when it does this causes
a hickup for nginx worker thread (since open is blocking). If you get
enough hickups, you wind up consuming all your worker threads and latency
for everybody suffers while waiting for these to complete (think flaky disk
that suddenly takes a really long time for each of its I/Os for one
example). We've hacked FreeBSD in various ways to reduce or eliminate this
delay.... In FreeBSD we have to translate from the pathname to a vnode, and
to do that we have to look up directories, indirect block tables, etc. All
these are surprising places that one could bottleneck at... And if you try
to access the vnode before all this is done, you'll wait for it (though in
the case of sendfile it doesn't matter since that's async and only affect
the one I/O)...

So I could see how having a async open could introduce a lot of hair into
the mix depending on how you do it. Without a robust callback/AST
mechanism, my brain is recoiling from the EALREADY errors in sockets for
things that are already in progress... reads and write are easy by
comparison :)  The kicker is that all of the kernel is callback driven. The
upper half queues the request and then sleeps until the lower half signals
it to wakeup. And that signal is often just a wakeup done from the
completion routine in the original request. All of that would be useful in
userland for high volume activity, none of it is exposed...

Warner

[-- Attachment #2: Type: text/html, Size: 3745 bytes --]

  reply	other threads:[~2020-06-04 14:20 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-31 11:09 Paul Ruizendaal
2020-05-31 16:05 ` Clem Cole
2020-05-31 16:46   ` Warner Losh
2020-05-31 22:01     ` Rob Pike
2020-06-01  3:32       ` Dave Horsfall
2020-06-01 14:58         ` Larry McVoy
2020-06-04  9:04           ` Peter Jeremy
2020-06-04 14:19             ` Warner Losh [this message]
2020-06-04 16:34               ` Tony Finch
2020-06-04 16:50               ` Larry McVoy
2020-06-05 16:00                 ` Dan Cross
2020-06-12  8:18                   ` Dave Horsfall
2020-06-01 16:58     ` Heinz Lycklama
2020-06-01 23:17 Noel Chiappa
2020-06-02  0:08 Noel Chiappa
2020-06-02  8:22 Paul Ruizendaal
2020-06-02 14:19 Paul Ruizendaal
2020-06-02 17:45 ` Paul Winalski
2020-06-02 17:59   ` arnold
2020-06-02 18:53     ` Paul Winalski
2020-06-02 19:18       ` Clem Cole
2020-06-02 21:15         ` Lawrence Stewart
2020-06-02 18:23   ` Dan Cross
2020-06-02 18:56     ` Paul Winalski
2020-06-02 19:23       ` Clem Cole
2020-06-02 20:13 Noel Chiappa
2020-06-02 20:43 ` Clem Cole
2020-06-02 22:14   ` Rich Morin
2020-06-03 16:31     ` Paul Winalski
2020-06-03 19:19       ` John P. Linderman
2020-06-06 13:29 Noel Chiappa

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='CANCZdfo289SQhA3tu5Z=RsDv3VrxgZ00r3M7mPNPCMEQiMvuQA@mail.gmail.com' \
    --to=imp@bsdimp.com \
    --cc=peter@rulingia.com \
    --cc=tuhs@tuhs.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).