Skip to content

Conversation

notgull
Copy link
Member

@notgull notgull commented Nov 17, 2024

The current no-std implementation is somewhat ineffecient, potentially
broken and relies on some slow data structures. The main reason why we
use this implementation is because we don't have a way to "lock" the
linked list, since there's no way to lock things in no-std. However,
many embedded platforms have a concept of a "critical section" that can
be used to exclusively lock something.

This PR adds an option to the "std" implementation that replaces the
existing Mutex with a usage of the critical-section crate. This is
enabled with the "critical-section" feature. This allows us to have the
advantages of the std-based implementation without needing to rely on
std for platforms that don't have it.

@notgull notgull requested a review from fogti November 17, 2024 19:41
The current no-std implementation is somewhat ineffecient, potentially
broken and relies on some slow data structures. The main reason why we
use this implementation is because we don't have a way to "lock" the
linked list, since there's no way to lock things in no-std. However,
many embedded platforms have a concept of a "critical section" that can
be used to exclusively lock something.

This PR adds an option to the "std" implementation that replaces the
existing Mutex with a usage of the critical-section crate. This is
enabled with the "critical-section" feature. This allows us to have the
advantages of the std-based implementation without needing to rely on
std for platforms that don't have it.

Signed-off-by: John Nunley <[email protected]>
Copy link
Member

@zeenix zeenix left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool stuff! I had planned to look into critical-sections for async-broadcast but never got around to it. However, since a-b depends on event-listener, this is required anyway. I just have a confusion and a nitpick to offer. :)

Since `std.rs` and `no_std.rs` no longer correspond to std and no_std,
I've renamed them based on the underlying algorithm used. `std.rs` is
now `intrusive.rs`, since it uses an intrusive linked list. `no_std.rs`
is now `slab.rs`, since it relies on a structure similar to the one used
in the `slab` crate.

Signed-off-by: John Nunley <[email protected]>
Copy link
Member

@fogti fogti left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great work, there is at least one small problem, tho.

@notgull notgull force-pushed the notgull/cs branch 2 times, most recently from a6bd06d to a90f8ff Compare November 23, 2024 19:00
- Untangle imports.
- Inline the entirely of ListLock into with_inner().
- Add documentation for feature.

Signed-off-by: John Nunley <[email protected]>
@notgull notgull merged commit afe606f into master Dec 4, 2024
10 checks passed
@notgull notgull deleted the notgull/cs branch December 4, 2024 16:17
@notgull notgull mentioned this pull request Dec 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

3 participants