You could do worse than Mach ports

[Matthew Dillon]

:I don't see why the COW scheme would be necessary.  If a user
:process writes to a page undergoing I/O, it deserves whatever it
:gets.  This can happen, for instance, if write(2) is invoked on a
:buffer from one thread while another thread writes to the buffer.
:The race is inherent, so protecting the pages and informing the VM
:system that they are COW can only decrease the size of the window,
:not eliminate it.  There are similar underlying assumptions for
:AIO and FreeBSD's pipe implementation.

    Most writes are buffered through the buffer cache and either delayed
    or asynchronized, so it is fairly easy to write out a file and then
    mmap() it and wind up getting stalled because the original writes
    are still in progress.  Another big problem is with paging... if
    the pageout daemon decides to write out a page which you then attempt
    to modify, your process will stall for no good reason.

    One also can hit serious with write stalls with directories,
    inodes, bitmap nodes, and so forth.

    The problems get exasperated on heavily loaded systems where a page
    will be marked for I/O but the I/O won't actually happen for a while
    due to the disk queue being full.  Pages can wind up in this limbo state
    for tens of milliseconds.

					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>