Why UNIX doesn't support events?

Joe Wells jbw at bucsb.UUCP
Tue Feb 14 04:43:20 AEST 1989


In article <1565 at anasaz.UUCP> john at anasaz.UUCP (John Moore) writes:
>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.

Well, you could use VMS instead.  It's event support isn't the best,
but at least it exists ... :-)

>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!)

Well, with VMS, on completion of a system call, you have two options.
You can have an event flag (pseudo-semaphore) set or you can have an
AST (function call like a signal handler) called.  I don't know if you
can prioritize disk requests.

For UNIX systems, try UMAX from Encore.  It supports two different
threads-style libraries for multiple tasks within one address space.
Multiple tasks with synchronous system calls is the easiest environment
in which to program multi-threaded real-time applications.

--
Joe Wells
INTERNET: jbw%bucsf.bu.edu at bu-it.bu.edu    IP: [128.197.2.9]
UUCP: ...!harvard!bu-cs!bucsf!jbw



More information about the Comp.unix.wizards mailing list