You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The cursors are maintained as U64s. There is another (original) branch that tried to build Turbine with a small int and handle ring buffer rollovers so that the library could operate for eternity without need for restart. This proved difficult. So for now, monotonically u64s are being used as absolute indices.
The max value of a u64 is 18,446,744,073,709,551,615. If we assume that Turbine can write 1 billion messages a second (for reference, it maxes out at 30m on my laptop) it would take 584.555 years before the u64 would overflow. This is a time-line I am willing to accept for now :)
Here is a tip, how you could solve this problem:
restrict the ring-buffer size to powers of 2, like 1024=2^10 etc.
it is then easy to prove, that a index overflow will be harmless. E.g. the last number before the overflow 2^64 - 1 will always index the last position in the ring buffer 2^k - 1 for any k < 64. So when the overflow happens with 2^64 == 0 it will be perfectly aligned, because it is exactly when you have to wrap around the ring buffer again.
I think this safe-guard is simple and efficient. No need for dynamic checks.
You could offer two constructors
a safe standard-constructor could only allow ring-buffer sizes as a power of 2, like 1024 = 2^10 - but panic if it's not a power of 2.
optionally an unsafe constructor could accept all ring-buffer sizes like 1023 - with the known overflow problems
PS: I think, you could even decrease u64 to u32 or u16 with this approach
The text was updated successfully, but these errors were encountered:
I read about your problem of cursor-overflow
Here is a tip, how you could solve this problem:
I think this safe-guard is simple and efficient. No need for dynamic checks.
safe
standard-constructor could only allow ring-buffer sizes as a power of 2, like 1024 = 2^10 - but panic if it's not a power of 2.unsafe
constructor could accept all ring-buffer sizes like 1023 - with the known overflow problemsPS: I think, you could even decrease u64 to u32 or u16 with this approach
The text was updated successfully, but these errors were encountered: