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