Standards Update, IEEE 1003.4: Real-time Extensions

[Chip Salzenberg]

Submitted-by: chip at tct.uucp (Chip Salzenberg)

According to brnstnd at kramden.acf.nyu.edu (Dan Bernstein):
>The underlying principle is that everything is a file *descriptor*.

No one disputes the significance of file descriptors.

Nevertheless, it is important not to underestimate the simplification
gained by using one namespace for all objects -- files, devices,
processes, hosts, IPC entities, etc.  A filesystem is good for files,
but a namespace is good for everything.  And if an object has a name,
and you want a file descriptor referring to that object, why invent a
new system call?  I'd rather continue using open().

>In reality, you initiate a network stream connection in two stages.
>First you send off a request, which wends its way through the network.
>*Some time later*, the response arrives.

This situation is easily modeled with open() and O_NDELAY.  Compare
the way Unix opens a modem control tty.  Normally, the open() call
will block until the carrier detect line is asserted.  However, the
O_NDELAY parameter to open() avoid the blockage.

Likewise, an open() on a TCP connection would block until the
connection succeeds or fails.  However, the O_NDELAY parameter would
allow the program to continue immediately, with provisional status of
"success".  The program could come back and check on the open() status
later, perhaps with an fcntl() call.

Devices are well-entrenched residents of the filesystem namespace.  So
far, all proposed reasons for keeping network connections out of the
filesystem would apply equally to devices.  Do we really want to leave
the filesytem free of everything except files?  That way lay CP/M.
-- 
Chip Salzenberg at Teltronics/TCT     <chip at tct.uucp>, <uunet!pdn!tct!chip>

Volume-Number: Volume 21, Number 138