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

[Peter da Silva]

In article <11968 at smoke.BRL.MIL> gwyn at brl.arpa (Doug Gwyn) writes:
> In article <CU318Y5xds13 at ficc.uu.net> peter at ficc.uu.net (Peter da Silva) writes:
> >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".

You sound like me (see my occasional diatribes against X in comp.windoows.*).
However with a conventional programming language it's the only way to do it,
unless you go all the way to UNIX processes... and that's too slow.

> >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.

Yes, that's an understatement. Replacing all System V's shm_* calls with
something like map_fd() (from Mach) would help.

But context switch overhead is still too high for realtime work.

> 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.

Multithreaded applications are difficult in many languuages, even when the
operating system is up to snuff. This is a language problem...

> 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.

First, you keep telling me I'm *forcing* processes to deal with awrite().
I'm not. I'm saying it should be an option.

Secondly, you can implement threads on top of asynchronous I/O calls. I've
done this for Forth under RSX-11. You have to have an explicit context
switch routine, but that simplifies the programming immensely anyway. You
just include checks for completed I/O in the swtch() routine. I laid out
the outline for such a routine in comp.lang.c some months ago, and at least
one person has turned it into a real concurrent "library" for C.

*If* UNIX supported await() and friends, then you could efficiently
implement a concurrent programming language. In fact, you could use C
plus a set of small routines to switch to a new context.

But it doesn't. Pity. Your serve.
-- 
 _--_|\  Peter da Silva. +1 713 274 5180. <peter at ficc.uu.net>.
/      \
\_.--._/ Xenix Support -- it's not just a job, it's an adventure!
      v  "Have you hugged your wolf today?" `-_-'