Right now storage is not limited by anything at all. Kchan currently breaks down (if it compiles) once u32::MAX is reached, since overflow means overwriting old post ids, which will cause random posts to disappear. So it seems that regardless of the approach, we should create some kind of id management system.
One idea would checking if the next id exists or not, and then deleting the oldest thread if yes, while incrementing the current id to the nearest of the free ids. This implies a limiting storage space by the amount of ids in the pool. Going with this approach, I think a cmdline argument for setting the max id would be very nice.
I don't have any other better ideas.
Right now storage is not limited by anything at all. Kchan currently breaks down (if it compiles) once `u32::MAX` is reached, since overflow means overwriting old post ids, which will cause random posts to disappear. So it seems that regardless of the approach, we should create some kind of id management system.
One idea would checking if the next id exists or not, and then deleting the oldest thread if yes, while incrementing the current id to the nearest of the free ids. This implies a limiting storage space by the amount of ids in the pool. Going with this approach, I think a cmdline argument for setting the max id would be very nice.
I don't have any other better ideas.
We could hold the size of the id pool and have a variable called level, which would correspond to the greatest power of 2 alignment which is free.
When the level becomes full, we do level -= 1 and continue from there, and when deleting we would set level to the highest freed alignment.
This should, in theory, allow us O(log n) complexity when searching for free ids.
We could hold the size of the id pool and have a variable called `level`, which would correspond to the greatest power of 2 alignment which is free.
When the level becomes full, we do `level -= 1` and continue from there, and when deleting we would set level to the highest freed alignment.
This should, in theory, allow us O(log n) complexity when searching for free ids.
Right now storage is not limited by anything at all. Kchan currently breaks down (if it compiles) once
u32::MAX
is reached, since overflow means overwriting old post ids, which will cause random posts to disappear. So it seems that regardless of the approach, we should create some kind of id management system.One idea would checking if the next id exists or not, and then deleting the oldest thread if yes, while incrementing the current id to the nearest of the free ids. This implies a limiting storage space by the amount of ids in the pool. Going with this approach, I think a cmdline argument for setting the max id would be very nice.
I don't have any other better ideas.
We could hold the size of the id pool and have a variable called
level
, which would correspond to the greatest power of 2 alignment which is free.When the level becomes full, we do
level -= 1
and continue from there, and when deleting we would set level to the highest freed alignment.This should, in theory, allow us O(log n) complexity when searching for free ids.