Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

aligning cursor-overflow #4

Open
colin-kiegel opened this issue Nov 27, 2015 · 0 comments
Open

aligning cursor-overflow #4

colin-kiegel opened this issue Nov 27, 2015 · 0 comments

Comments

@colin-kiegel
Copy link

I read about your problem of cursor-overflow

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant