From: Peter Jeremy <peter@rulingia.com>
To: Larry McVoy <lm@mcvoy.com>
Cc: The Eunuchs Hysterical Society <tuhs@tuhs.org>
Subject: Re: [TUHS] non-blocking IO
Date: Thu, 4 Jun 2020 19:04:36 +1000 [thread overview]
Message-ID: <20200604090436.GJ279@server.rulingia.com> (raw)
In-Reply-To: <20200601145801.GE22016@mcvoy.com>
[-- Attachment #1: Type: text/plain, Size: 1362 bytes --]
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.
--
Peter Jeremy
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 963 bytes --]
next prev parent reply other threads:[~2020-06-04 9:05 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 [this message]
2020-06-04 14:19 ` Warner Losh
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=20200604090436.GJ279@server.rulingia.com \
--to=peter@rulingia.com \
--cc=lm@mcvoy.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).