17 Dec
2024
17 Dec
'24
1:47 a.m.
Steffen Nurpmeso wrote in
<20241216194043.PqDb-or7(a)steffen%sdaoden.eu>:
|Clem Cole wrote in
| <CAC20D2PfMx=tox0NmLYCi_7345BSr8yoCQZTRVspS8YxAawYdg(a)mail.gmail.com>:
||On Mon, Dec 16, 2024 at 10:40 AM Douglas McIlroy <
||douglas.mcilroy(a)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