On Sun, Feb 15, 2026 at 09:24:32PM -0500, Alyssa M via 9fans wrote:
> I think the difficulty here is thinking about this as memory mapping. What
> I'm really doing is deferred I/O. By the time a read completes, the read has
> logically happened, it's just that not all of the data has been transferred
> yet.
> That happens later as the buffer is examined, and if pages of the buffer are
> not examined, it doesn't happen in those pages at all.
>
But isn't this what the buffer cache does? My concern with this scheme
is the sharing (concurrent accesses, even with only one rw and several
read-only: what are the read-only ones really reading and when): if
there is a kernel side resources server, only when the writing process
does "commit", the data is officially modified and with a central
server the information can be propagated. With a per process mapping,
on what criterium will the data be marked as "officially" modified
with the concurrent accesses having to be informed? If the process has
(as it should) to inform (to commit modified data) and don't see what
is different from the traditional scheme and I don't get what it
improves---my gut feeling is the reverse: it would be more tricky to
get it right and the complexity will certainly not improve the
performance.
--
Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
http://www.kergis.com/
http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
------------------------------------------
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/Te8d7c6e48b5c075b-M0571d4715430928ca6543e92
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
