[TUHS] Re {TUHS} Synchronous vs Asynchronous IO in Unix

[TUHS] Re {TUHS} Synchronous vs Asynchronous IO in Unix

[Doug McIlroy]

Unix was what the authors wanted for a productive computing environment,
not a bag of everything they thought somebody somewhere might want.
One objective, perhaps subliminal originally, was to make program
behavior easy to reason about. Thus pipes were accepted into research
Unix, but more general (and unruly) IPC mechanisms such as messages
and events never were.

The infrastructure had to be asynchronous. The whole point was to
surmount that difficult model and keep everyday programming simple.
User visibility of asynchrony was held to a minimum: fork(), signal(),
wait(). Signal() was there first and foremost to support SIGKILL; it
did not purport to provide a sound basis for asynchronous IPC.
The complexity of sigaction() is evidence that asynchrony remains
untamed 40 years on.

Doug

[TUHS] Re {TUHS} Synchronous vs Asynchronous IO in Unix

[Dan Cross]

On Mon, Sep 21, 2015 at 10:02 AM, Doug McIlroy <doug at cs.dartmouth.edu>
wrote:

> Unix was what the authors wanted for a productive computing environment,
> not a bag of everything they thought somebody somewhere might want.
> One objective, perhaps subliminal originally, was to make program
> behavior easy to reason about. Thus pipes were accepted into research
> Unix, but more general (and unruly) IPC mechanisms such as messages
> and events never were.
>
> The infrastructure had to be asynchronous. The whole point was to
> surmount that difficult model and keep everyday programming simple.
> User visibility of asynchrony was held to a minimum: fork(), signal(),
> wait(). Signal() was there first and foremost to support SIGKILL; it
> did not purport to provide a sound basis for asynchronous IPC.
> The complexity of sigaction() is evidence that asynchrony remains
> untamed 40 years on.


Point of order: Does it really say this, or rather does it say that trying
to retrofit it into the Unix model, which was not designed with the sort of
thing in mind, has proven to be difficult?

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150925/a5acba92/attachment.html>

[TUHS] Re {TUHS} Synchronous vs Asynchronous IO in Unix

[Dave Horsfall]

On Mon, 21 Sep 2015, Doug McIlroy wrote:

> Signal() was there first and foremost to support SIGKILL; it did not 
> purport to provide a sound basis for asynchronous IPC.

Yeah, brother.  In a previous life, I got burned very badly when I relied 
upon signals Doing the Right Thing [tm].

I think it was dump/restor, on a BSDi box; the damned thing communicated 
betwixt its child processes with signals, and I lost every backup tape 
without realising it.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."
              Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn!

[TUHS] Re {TUHS} Synchronous vs Asynchronous IO in Unix

[Clem Cole]

Sadly I have heard a number of stories/expereiences like this.   That's why
the original Posix.4 specification had a new API: asynchronous system traps
(AST) similar to what most other real time systems have had such as RSX,
VMS or VxWorks for that matter and true async I/O calls. The idea was
instead of trying to "fix" signals or read/write, put a new (optional) API
in that had the proper semantics for a real IPC (like being queued, having
priority etc...).    The AST call was later removed and z queued hacked was
splitter into signals although async I/O did stay.   I was sad to see AST
go.  I always felt it was better to not "fix" it, but rather offer and
optional way that me the needs of people that wanted it.

FWIW:  I've implemented AST a couple of times in my career into UNIX
systems.   Very handy why you really want those semantics.

Clem

On Fri, Sep 25, 2015 at 6:05 PM, Dave Horsfall <dave at horsfall.org> wrote:

> On Mon, 21 Sep 2015, Doug McIlroy wrote:
>
> > Signal() was there first and foremost to support SIGKILL; it did not
> > purport to provide a sound basis for asynchronous IPC.
>
> Yeah, brother.  In a previous life, I got burned very badly when I relied
> upon signals Doing the Right Thing [tm].
>
> I think it was dump/restor, on a BSDi box; the damned thing communicated
> betwixt its child processes with signals, and I lost every backup tape
> without realising it.
>
> --
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will
> suffer."
>               Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn!
>
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150925/f8c1ae79/attachment.html>

[TUHS] Re {TUHS} Synchronous vs Asynchronous IO in Unix

[Larry McVoy]

On Fri, Sep 25, 2015 at 07:16:41PM -0400, Clem Cole wrote:
> Sadly I have heard a number of stories/expereiences like this.   That's why
> the original Posix.4 specification had a new API: asynchronous system traps
> (AST) similar to what most other real time systems have had such as RSX,
> VMS or VxWorks for that matter and true async I/O calls. 

Tcl (really tk, but tcl implements it) has this.  You bind an event to 
a subroutine and when the event happens it jumps into that subroutine,
just like an AST (with similar rules about calling context etc).

Mainly used for GUI programming where it fits nicely but one useful thing
is you can post fake events.  That makes it possible to write regressions
for gui code which is *awesome*.

--larry "still using tcl/tk after all these years" mcvoy

P.S.  We're not crazy, we implemented a C like language that compiles down
to tcl byte codes so we don't have to deal with tcl very much.  Here's
what that looks like, this is a little script that I use like

tail -f access.log | awk { print $1, $7 } | bk tclsh dns.l

It's like C with some perl goodness thrown in:

void
main(void)
{
        string  buf;
        string  ip, file;

        while (buf = <>) {
                if (buf =~ /^\s*([0-9.]+)\s*$/) {
                        ip = $1;
                        buf = `host ${ip}`;
                        if (buf =~ /not found/ || buf =~ /has no PTR record/) {
                                printf("%s\n", ip);
                        } else unless (skip(buf)) {
                                buf =~ /([^ ]+$)/;
                                printf("%s\n", $1);
                        }
                        continue;
                }
                buf =~ /([0-9.]+)\s+(.*)/;
                ip = $1;
                file = $2;
                if (file =~ /assets/) continue;
                if (file =~ /favicon/) continue;
/*
                unless (exists("/home/bk/homepage-live/public/${file}")) {
                        file .= " (NOT FOUND)";
                }
*/
                buf = `host ${ip}`;
                if (buf =~ /not found/ || buf =~ /has no PTR record/) {
                        printf("%s %s\n", ip, file);
                        continue;
                }
                if (skip(buf)) continue;
                buf =~ /([^ ]+$)/;
                printf("%s %s\n", $1, file);
        }
}

int
skip(string host)
{
        switch (host) {
            case /crawl/:
            case /spider/:
            case /msnbot/:
                return (1);
        }
        return (0);
}

[TUHS] Re {TUHS} Synchronous vs Asynchronous IO in Unix

[Dave Horsfall]

On Fri, 25 Sep 2015, Larry McVoy wrote:

> P.S.  We're not crazy, we implemented a C like language that compiles 
> down to tcl byte codes so we don't have to deal with tcl very much.  
> Here's what that looks like, this is a little script that I use like
> 
> tail -f access.log | awk { print $1, $7 } | bk tclsh dns.l
> 
> It's like C with some perl goodness thrown in:

Dang it; you're making me learn a new language!

I used to joke that I've used as many languages as I am old; I turn 63 
next month, so you've just added one...

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."
              Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn!

[TUHS] Re {TUHS} Synchronous vs Asynchronous IO in Unix

[John Cowan]

Dave Horsfall scripsit:

> Dang it; you're making me learn a new language!

I read the paper when it was last mentioned on the list, and it's indeed
impressive: more like awk than perl, except in a few particulars.

>               Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn!

Someone asked me once how I dared to use the .sig below.  I replied
that I come from New Jersey, where the very hero sandwiches in kids'
school lunches are made from shoggoth meat, and I now live in NYC,
where the banks foreclosed on sunken R'lyeh.  They're probably going
for a controlling interest in blue-litten K'nyan, red-litten Yoth, and
Black N'kai even now.  Gotta diversify in these degenerate days, y'know.

(About the name: Abdul al-Hazred is an ill-formed expression in Arabic,
having two definite articles in a row.  Correcting it to Abdullah
al-Hazred, which inserts the Divine Name between the articles, gives
the reasonable Arabic name -- or more likely, alias -- "servant of God
the Forbidden".  IRL it's an exoticized version of Hazard, the surname
of some of Lovecraft's ancestors.)

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
La mayyitan ma qadirun yatabaqqa sarmadi
Fa idha yaji' al-shudhdhadh fa-l-maut qad yantahi.
                --Abdullah al-Hazred, Al-`Azif

[TUHS] Re {TUHS} Synchronous vs Asynchronous IO in Unix

[Ramakrishnan Muthukrishnan]

On Sat, Sep 26, 2015 at 4:53 AM, Larry McVoy <lm at mcvoy.com> wrote:
> On Fri, Sep 25, 2015 at 07:16:41PM -0400, Clem Cole wrote:
>> Sadly I have heard a number of stories/expereiences like this.   That's why
>> the original Posix.4 specification had a new API: asynchronous system traps
>> (AST) similar to what most other real time systems have had such as RSX,
>> VMS or VxWorks for that matter and true async I/O calls.
>
> Tcl (really tk, but tcl implements it) has this.  You bind an event to
> a subroutine and when the event happens it jumps into that subroutine,
> just like an AST (with similar rules about calling context etc).
>
> Mainly used for GUI programming where it fits nicely but one useful thing
> is you can post fake events.  That makes it possible to write regressions
> for gui code which is *awesome*.
>
> --larry "still using tcl/tk after all these years" mcvoy
>
> P.S.  We're not crazy, we implemented a C like language that compiles down

Larry:

This is really interesting. The C-like language you are referring to
here is the "L" language?

The introductory paper linked from here: <http://wiki.tcl.tk/17068> is
giving 404. Would you mind fixing the link or pointing me to another
copy of the paper? My google-fu failed to find a copy of the paper
elsewhere.

Ramakrishnan