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

split a StaticThingBuf into a MPSC #17

Closed
hawkw opened this issue Dec 9, 2021 · 0 comments · Fixed by #23
Closed

split a StaticThingBuf into a MPSC #17

hawkw opened this issue Dec 9, 2021 · 0 comments · Fixed by #23
Assignees
Labels
enhancement New feature or request

Comments

@hawkw
Copy link
Owner

hawkw commented Dec 9, 2021

it would be nice to have a totally-non-allocating MPSC variant for embedded etc where instead of an Arc<ThingBuf<T>> the queue is stored in an &'static ThingBuf<T>. we can now do this even with waiting tasks now that #16 added an intrusive wait queue that doesn't allocate.

i think that the API for this will have to be something like:

static SOME_QUEUE: thingbuf::StaticMpsc<Event, 1024> = thingbuf::StaticMpsc::new();

fn main() {
    let (tx, rx) = SOME_QUEUE.try_split()
         .expect("queue split into sender/receiver pair more than once");
    // ...
}

because that's the only nice way to get all the important stuff in a static initializer and hand out &'static refs to it to a sender/receiver pair. i don't think we can just add a try_split to the normal StaticThingbuf type since the shared state also needs rx/tx wait cells...

@hawkw hawkw added the enhancement New feature or request label Dec 9, 2021
@hawkw hawkw self-assigned this Dec 9, 2021
@hawkw hawkw closed this as completed in #23 Dec 25, 2021
hawkw added a commit that referenced this issue Dec 25, 2021
This branch adds new `StaticChannel` types that can be used to construct
statically allocated MPSC channel variants. The static channels can be
used without requiring *any* heap allocations. This is intended
primarily for embedded systems and bare metal programming where
allocators may not be available or heap memory is constrained.

Closes #17

Signed-off-by: Eliza Weisman <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant