Share memory by copying.

[ncruces]

"Don't communicate by sharing memory, share memory by communicating."

I'm not entirely convinced this is a good idea.
Still, it repeatedly passes all tests locally and has zero dependencies.
Could probably address #75 (Windows) as well.

[ncruces]

Checks for write-write conflicts indicate that there are none, which maybe indicates that this might be a viable, if slow, way of doing this.

I'll add further runtime checks to better understand behavior (what writes happen, and when).

[ncruces]

I'm beginning to warm up to this. It looks like a safe, if inefficient, way of keeping memory in sync.

The WAL-index file starts with a header.
This header starts with two 48 byte, checksummed, copies of the same information, which are accessed independently between memory barriers.
The checkpoint information that follows uses 4 byte aligned words.

Finally, we have the WAL-index hash tables, which are only modified holding the exclusive WAL_WRITE_LOCK.

Since all the data is either redundant+checksummed, 4 byte aligned, or modified under an exclusive lock, the copies being done should correctly keep memory in sync.

This looks good enough to submit as is.

Windows can likely reuse significant portions of this. It could trade the in memory locks for file locks, map the file in main memory, and support multiple processes sharing the WAL. If so, care needs to be taken that copies will no longer be made under a lock (they may need to be made on the right side of a file lock).