Re: scrolling optimization + asynchronous updates impossible

[Roland McGrath]

Some things might use the vt100 scrolling region, which behaves like an
atomic delete+insert line.

File change notifications are always delivered asynchronously.  So they can
only ever tell you what part of the file to examine later, not exactly what
all has happened there at the time you are looking.  Which is to say, it
serves as a wakeup and a clipping region for what might have changed before
the wakeup was sent, but it doesn't provide a complete undo-record of the
changes to the file.  

I think this points to the fundamental overhead of your current console
design.  The functional splits make sense, but one way or another flicker
just seems real likely.  

I have an idea for a way to make this style of update correct, though it
has overhead just as big or bigger.  That is, a different form of
notification that preserves all the information.  What I'm thinking of is a
request for "update propagation" that would give a file port on which the
fs would send regular io RPCs (with no reply ports) as notification of
changes.  It could in the trivial case reflect every io RPC it performs,
but would be allowed to coalesce into larger chunks at will (including
perhaps sending an io_write with interpersed bits of unchanged data).  We
could then add a call or two something like io_edit to perform
insertion/deletion.  Any fs could implement this as an optimization over
combinations of extend/truncate, read some, write it elsewhere, or punt
with a canonical error for a case it didn't want to think about (or just
implement the data copying itself).  For a disk filesystem this could be a
useful optimization for some other programs to use, so that
inserting/deleting a block or more just diddles the inode instead of
touching the data in the whole blocks.  With that, you could have emacs
mmap mkfile'd nodes for buffers and use io_edit for gap operations--then
writing the buffer out just does dir_link on the node.  Anyway, a random
thought.