async I/O (was: Is there a select()-like call for message queues?)

[Doug Gwyn]

In article <CU318Y5xds13 at ficc.uu.net> peter at ficc.uu.net (Peter da Silva) writes:
>First, a nitpick. By 1974 UNIX was basically in its current form, and its
>design goals must have been established earlier than that. But that's just
>a nitpick.

Yes, Ken Thompson was thinking about these issues too, as far back as
1969 for sure and probably well before that.

>Secondly, I'm not suggesting that applications be forced to explicitly
>deal with asynchronism. I just believe that since the real world is
>asynchronous you should be able to deal with it.

I would rather have it under control than have to deal with it ad lib.

>Also, the event-loop construct has considerable success in the real world
>for dealing with asynchronous events.

Ha!  Practically everybody I know who has had to program event loops
thinks "there has to be a better way".  The fundamental problem with
event loops is that it forces the application to maintain state
information merely to properly schedule the application's actions.
This (tedious and error-prone) bookkeeping is unnecessary when using
better methods for handling asynchronism.

>Unfortunately, UNIX doesn't support a sufficiently fine-grained process
>structure to allow this [CSP] to be generally used.

Actually, it does pretty well, but in most implementations its IPC needs
improvement.  Also, there is no reasonable programming language for
exploiting this approach other than the shell language, which is too
limited and difficult to use in this area.

>I'm sure it can. But not under UNIX as it exists, and not under any
>extension of UNIX that I've seen that still remains close to the source.

The issue was the best way to extend UNIX to give applications better
control over asynchronism.  I made suggestions for better methods than
forcing processes to deal with awrite() etc.