Subject: Re: heavy use of mmap() & regex ?
To: None <current-users@NetBSD.ORG>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Date: 04/30/1998 17:48:36
>> 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"
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B