[TUHS] mmap, was SCCS, TeamWare, BitKeeper, and Git

[Steffen Nurpmeso]

Steffen Nurpmeso wrote in
 <20241216194043.PqDb-or7 at steffen%sdaoden.eu>:
 |Clem Cole wrote in
 | <CAC20D2PfMx=tox0NmLYCi_7345BSr8yoCQZTRVspS8YxAawYdg at mail.gmail.com>:
 ||On Mon, Dec 16, 2024 at 10:40 AM Douglas McIlroy <
 ||douglas.mcilroy at dartmouth.edu> wrote:
 ||
 ||>>> Does anyone know whether there are implementations of mmap that
 ||>>> do transparent file sharing? It seems to me that should be possible by
 ||>>> making the buffer cache share pages with mmapping processes.
 ||>
 ||>> These days they all do.  The POSIX rationale says:
 ||>
 ||>> ... When multiple processes map the same memory object, they can
 ||>> share access to the underlying data.
 ||>
 ||> Notice the weasel word "can". It is not guaranteed that they will do so
 ||> automatically without delay. Apparently each process may have a \
 ||> physical\
 ||> ly
 ||> distinct copy of the data, not shared access to a single location.

I think it was in FreeBSD when sed(1) once got an optimization to
mmap(1) data, but it was reverted because of crashes caused by
concurrent modifications.  (There definetely was something like
this, but FreeBSD / sed is nothing but what i remember.)

But there is no weasel word in the real standard text, but lots of
"shall".  The only "can" there are

  There may be implementation-defined limits on the number of
  memory regions that can be mapped (per process or per system).

and

  If such a limit is imposed, whether the number of memory regions
  that can be mapped by a process is decreased by the use of
  shmat( ) is implementation-defined.

which are no "weasel-can's".

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
|
|And in Fall, feel "The Dropbear Bard"s ball(s).
|
|The banded bear
|without a care,
|Banged on himself for e'er and e'er
|
|Farewell, dear collar bear