Both SMRs now passing their (prety minimal but actually testinge everything) tests, at least on x86_64.
Will run a build-system wide build in the morning.
Been busy visiting museums the last three days.
However, have now a compiling freelist which uses offsets (i.e. for shared memory use).
Next, tests.
Then have to make offset versions of all the existing data structures.
I’ve opted to use a new API in each case, so the docs are simple to explain, and it seems reasonable that when an instance is being used with shared memory, it will be distinct in its use to other data structures. It would be possible to overload the pointers in the current data structures, so they’re used for offsets, and then you could do things like pop from a shared memory freelist and push to a non-shared memory freelist, but then you have to explain to users all the caveats about use, and users have to make sure they don’t blunder into error.
It also strictly breaks ANSI, since it means I have to assume a pointer type can hold all the values in a ptrdiff_t. I can’t imagine a platform where this isn’t true, but I know I don’t know much.
Been making position independent versions of the data structures.
So far : freelist, stack, queue (unbounded many many), queue (unbounded single single).
Made tests for the position independent stack, they pass.
Need to make tests for the rest, and also make the position indepenent btree and lists.
Have to think about the freelist elimination array and position independence (I think it’s just okay - works no changes) and have to think about position independence and the SMR methods.
Again, I think they just work - have to switch them over to offsets internally, but that’s all - so it should be possible to make position independent versions of the SMR-using data structures.
The next thing though will be a quick extra benchmark for the freelist, to properly benchmark the elimination array. Gym first though :-)