>> A while ago, NetBSD had a bug that meant that reads and writes via
>> mmap() and accessing the memory were decoupled from reads and writes
>> via read() and write().

> I suspect that you're slightly tongue-in-cheek here, but still: I'd
> like to contend that this is _not_ a bug, just a design choice.

I wasn't deliberately being tongue-in-cheek; I believe this is a bug,
pure and simple.  Two ways (read/write vs mmap) of accessing a single
object (the underlying file) are defined, but changes made via one
mechanism are not seen via the other until some ill-defined event not
under anyone's direct control occurs.

> [...] I'd further like to point out that the really bad design choice
> is mmap() itself, which has so poor error handling that it forces
> programmers to mix their metaphors, so to speak, and use both mmap
> and read/write level I/O on the same file objects.

I'm not sure what you're talking about here.  I don't see mmap as
having poor error handling, nor do I see why any single program would
want to mix read/write and mmap.  The problem arises primarily when two
programs try to operate on the same file at once, one using read/write
and the other using mmap.

> If mmap() and friends were specified more completely to begin with,
> it would be possible to fully separate the use of the two access
> methods, and there would be no problem.

What relevant aspects of mmap are unspecified?  If they were specified,
how would it help?  How *can* it be possible to "fully separate" the
two access methods, as long as (a) they're both accessing the same
underlying object (the file) and (b) they're built around such
different paradigms (read/write use the "everything is a stream of
bytes" paradigm, while mmap uses the "everything is a block of memory"
paradigm)?

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B