-
Notifications
You must be signed in to change notification settings - Fork 13
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
Generic type support #11
Comments
Hi, Thanks for bringing this up. I don't think there's anything fundamental that would prevent this, however it's not clear to me what additional use case we'd support with this addition that's not already covered by one of the regular spsc queues. What's your use case? |
I have a case in which I need to perform a memcopy from a device BRAM. I need the ability to get a continuous chunk of memory but since I know the device stored u64 values I would like the ring buffer to guarantee the alignment of the pointer to avoid unsafe to transmute it from a u8 buffer. |
Does this makes sense to you @utaal ? |
Thanks for bumping this conversation. I think it does - I was trying to think through potential issues, but it sounds like if we're careful when allocating, and if you know you'll always need allocations that are multiples of 64bits and u64-aligned, it should be good. Did you say you're interested in making a PR? If you do I can commit to review it promptly. Just note that I may realize that something is problematic only when I see the code. |
I am interested in looking at but my bandwidth is not great. I will let you know when I start looking at it. |
Hi,
I am wondering if there is anything in the theory of operation of the buffer that would prevent to make it generic over its type.
For example, I could have some use for an spsc_bip_buffer of u32. If there is nothing blocking from a fundamental point of view I may be able to look into making a PR.
Best
The text was updated successfully, but these errors were encountered: