Standards Update, IEEE 1003.4: Real-time Extensions

[Peter da Silva]

Submitted-by: peter at ficc.ferranti.com (Peter da Silva)

In article <548 at usenix.ORG> brnstnd at kramden.acf.nyu.edu (Dan Bernstein) writes:
> I disagree. I consider it an excellent example of how the designers of
> UNIX realize that all *reliable*, *static*, *local* (or virtually local)
> I/O objects potentially visible to more than one process belong in the
> filesystem namespace.

Like "/dev/tty"? I think you've got some semantic gap here between what's
appropriate for a file versus what's appropriate for a file descriptor. An
arbitrary failure on an open file descriptor causes problems... but that
doesn't keep socket() from returning an fd. An arbitrary failure or an
arbitrary delay on an open call is perfectly reasonable: programs expect
open to fail. They depend on write() working.

And serial lines are subject to all the "hazardous" behaviour of network
connections. An open can be indefinitely deferred. The connection, especially
over a modem, can vanish at any time. Why not take *them* out of the namespace
as well?

> You can read() or
> write() reasonable I/O objects through file descriptors. Very few
> programs---the shell is a counterexample---need to worry about what it
> takes to set up those file descriptors.

And that's the problem, because the shell is the program that is used to
create more file descriptors than just about anything else. If the shell
had a syntax for creating sockets and network connections we wouldn't be
having this discussion... but then if it did then you might as well make
it be via filenames...

And look where this discussion started... over shared memory and messages
and semaphores being in a separate namespace. But shared memory and message
ports are all:

	reliable,
	static,
	and local...

at least as much as processes.
-- 
Peter da Silva.   `-_-'
+1 713 274 5180.   'U`
peter at ferranti.com

Volume-Number: Volume 21, Number 150