summaryrefslogtreecommitdiffstats
path: root/include/framework/structure/BufferView.h
Commit message (Collapse)AuthorAgeFilesLines
* Concurrency testing and bug fixesDouglas B. Rumbaugh2024-01-151-1/+9
|
* Various single-threaded bug fixesDouglas B. Rumbaugh2024-01-151-4/+14
|
* Initial integration of new buffering scheme into frameworkDouglas Rumbaugh2024-01-121-0/+4
| | | | | It isn't working right now (lotsa test failures), but we're to the debugging phase now.
* BufferView.h: Hopefully the last necessary tweak to the move semantics stuffDouglas Rumbaugh2024-01-121-24/+2
| | | | | | | | You can't move assign an std::Bind, but you can move construct it. So I had to disable the move assignment operator. This means that when you change the BufferView ownership over to, say, a QueryBufferState object, you need to do it by passing std::move(buffview) into a constructor call only--you cannot assign it.
* InternalLevel update and testsDouglas Rumbaugh2024-01-111-10/+34
| | | | | Plus some assorted fixes for move semantics stuff in BufferView that accompanied these changes.
* BufferView: enforce move semanticsDouglas Rumbaugh2024-01-111-2/+19
| | | | | | Because a BufferView's lifetime is so tightly linked to the lifetime of regions of the buffer, it can't be copied without potentially breaking things.
* Fixed some potential buffer-related concurrency bugsDouglas Rumbaugh2024-01-111-14/+31
|
* MutableBuffer+View: Implementation with unit testsDouglas Rumbaugh2024-01-101-14/+18
|
* Initial update of buffer to new specificationsDouglas B. Rumbaugh2024-01-091-73/+25
| | | | | | | | | | | | | | | | | | | There are a few minor issues that this introduces, however. Global tracking of a lot of secondary information, such as weights for WIRS/WSS, or the exact number of tombstones will need to be approached differently than they have been historically with this new approach. I've also removed most of the tombstone capacity related code. We had decided not to bother enforcing this at the buffer level anyway, and it would greatly increase the complexity of the problem of predicting when the next compaction will be. On the whole this new approach seems like it'll simplify a lot. This commit actually removes significantly more code than it adds. One minor issue: the currently implementation will have problems in the circular array indexes once more than 2^64 records have been inserted. This doesn't seem like a realistic problem at the moment.
* Comment and License updatesDouglas Rumbaugh2023-11-071-1/+1
|
* General Comment + Consistency updatesDouglas Rumbaugh2023-10-301-1/+1
|
* DynamicExtension: adjusted a few operations to ensure conistencyDouglas Rumbaugh2023-10-301-0/+4
| | | | | | | | | | | | get_memory_usage, get_aux_memory_usage, get_record_count, get_tombstone_count, and create_static_structure have been adjusted to ensure that they pull from a consistent epoch, even if a change-over occurs midway through the function. These functions also now register with the epoch as a job, to ensure that the epoch they are operating own isn't retired midway through the function. Probably not a big issue for the accessors, but I could see it being very important for create_static_structure.
* Concurrency updates + fixes for compile errorsDouglas Rumbaugh2023-10-301-2/+2
|
* Began moving to an explicit epoch-based systemDouglas Rumbaugh2023-10-231-0/+124
I started moving over to an explicit Epoch based system, which has necessitated a ton of changes throughout the code base. This will ultimately allow for a much cleaner set of abstractions for managing concurrency.