Incremental Transactional Implementation

[spacejam]

• agree on explicit user-facing interface
• agree on a "dream architecture" to work toward (currently thinking cicada)
• identify the required interfaces to get there
• build out dumb versions of them that achieve the same functional purpose but with less sexy underlying implementation
• prioritize optimization efforts to reach the dream architecture

• versioning: This will likely involve using the Tree as an index pointing to per-key page ID's with N2O version ordering, sharing the same pagecache.
• gc: initially can just punt cleanup to crossbeam-epoch
• 2i: not implementing initially
• cc: TBD, need to more thoroughly document the required components for cicada and then plan a path of least resistance

[spacejam]

The simplest way to get most of the desired functionality here is with a simple mcas operation that takes a vector of (Key, Option<Value>, Option<Value>). This lets us sidestep versioning, and phantom prevention, and merge handling completely for now.

[pythonesque]

Just popped in to put in the good word for Cicada's architecture. I think it will be very hard to do better; in particular its single threaded performance is very good compared to most other solutions that optimize for multicore (I am tempted to think a large part of this is the optimistic inlining, but as the paper shows all of the components are important).

[spacejam]

superseded by #382