Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!ncar!noao!asuvax!anasaz!john
From: john@anasaz.UUCP (John Moore)
Newsgroups: comp.unix.wizards
Subject: Re: Why UNIX doesn't support event?
Summary: Desire for several new Unix OLTP features
Keywords: UNIX is a lousy real-time, OLTP or datacom platform!
Message-ID: <1565@anasaz.UUCP>
Date: 12 Feb 89 18:50:48 GMT
References: <3921@cbnews.ATT.COM> <15886@mimsy.UUCP>
Reply-To: john@anasaz.UUCP (John Moore)
Distribution: usa
Organization: Anasazi Inc, Phoenix AZ
Lines: 48

In article <15886@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
]In article <3921@cbnews.ATT.COM> rock@cbnews.ATT.COM (Y. Rock Lee) writes:
]>Inside UNIX KERNEL, one can also sleep on an event(address)
]>and expect to be waken up later by someone else.
]>But, on the user level a process can only sleep on TIME.
]>... What is the philosophy behind [this]?
]
]Not true (one can also await a signal with pause() or sigpause()),
]but the essential difference is that, while the kernel is multithreaded
]and thus needs a fancy scheduling mechanism, Unix processes are
](normally) single-threaded so such a primitive is pointless.
]
]You can always write your own, by writing your own scheduler.

I wish this were true! How does one write a SINGLE process that
will wait for a character to appear on two different tty devices?
How about waiting for a semaphore at the same time? I realize that
all of this can be done by splitting the problem into a whole
bunch of processes, but this is both costly of system resources
and results in a more complex applications architecture.

Unix is SERIOUSLY DEFICIENT in event handling. In our data communications
systems that we do on Unix PC's, we wrote our own multi-event wait
device driver to get around this. We'd much rather have good
event management built into the kernel and standardized so that
we can do things in a portable fashion.

While I'm at it, I'd also like to mention that UNIX standard disk
I/O is DEFICIENT. For serious transaction processing it would
be nice to have kernel support for:
  (1) No-wait disk I/O: issue the request, get an event when I/O is
      done.
  (2) Good applications level notification and control for disk
      errors (a la GCOS-3 GEPR).
  (3) Prioritization of disk requests
  (4) Absolute, settable process priorities as an option. (Yeah,
      I know, this has nothing to do with disk I/O. But I thought
      I'd throw it in!)

The best OLTP enhancements that I have seen are done by Pyramid -
now when is AT&T going to wake up and include their sorts of enhancements
in standard Unix so we can use them across a range of machines?

-- 
John Moore (NJ7E)           mcdphx!anasaz!john asuvax!anasaz!john
(602) 861-7607 (day or eve) 
The opinions expressed here are obviously not mine, so they must be
someone else's. :-)