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

docs: Revise notes for example std_global_allocator.rs #36

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

polarathene
Copy link
Contributor

@polarathene polarathene commented Oct 7, 2024

I noticed a recent commit hoisted the two type comments from their contextual proximity to relevant code, while the START_ARENA line seems to have no relevance separating the two comment sections. Grouped them together as bullet point notes.

The two type focused comments are more explicit about communicating that early now, followed by the description for the choice (it's not really communicated why spin::Mutex is sensible to the user, but I suppose that's better context than none). Was vaguely touched on here, I could add a link to that for reference if considered helpful?

It's not clear what the Miri comment refers to by "this", other than the relation to the global allocator attribute. Nor what "if you can't have that" is referring to (the violation being potentially valid, or a false-positive from Miri?). Additionally corrected a typo + corrected the file name that was changed since the comment was written.

The shorter README equivalent uses ARENA instead of START_ARENA, was START_ meant to communicate any additional context?

  • This isn't an area of expertise for me, so while it might not matter to someone more familiar, for a newbie however there might be some benefit in adding context.
  • Your response in this PR mentions multiple arena's, so I guess the intent of START_ is an initial arena.

Group all notes together, revision pass on phrasing.
@polarathene polarathene changed the title docs: Revise notes for std_global_allocator.rs docs: Revise notes for example std_global_allocator.rs Oct 7, 2024
// note:
// - Miri thinks this violates stacked borrows upon program termination.
// - This only occurs with `#[global_allocator]`.
// - Use the allocator API if you can't have that. Perhaps check out `examples/stable_allocator_api.rs`?
Copy link
Contributor Author

@polarathene polarathene Oct 7, 2024

Choose a reason for hiding this comment

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

Alternative, although it'd be good to know what "if you can't have that" is referring to.

Suggested change
// - Use the allocator API if you can't have that. Perhaps check out `examples/stable_allocator_api.rs`?
// - Consider using the allocator API if you can't have that (see: `examples/stable_allocator_api.rs`)

#[global_allocator]
static ALLOCATOR: Talck<spin::Mutex<()>, ClaimOnOom> = Talc::new(unsafe {
ClaimOnOom::new(Span::from_const_array(std::ptr::addr_of!(START_ARENA)))
}).lock();
ClaimOnOom::new(Span::from_const_array(std::ptr::addr_of!(START_ARENA)))
Copy link
Contributor Author

@polarathene polarathene Oct 7, 2024

Choose a reason for hiding this comment

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

Restore no_std compatibility, matches README equivalent:

Suggested change
ClaimOnOom::new(Span::from_const_array(std::ptr::addr_of!(START_ARENA)))
ClaimOnOom::new(Span::from_const_array(core::ptr::addr_of!(START_ARENA)))

@SFBdragon
Copy link
Owner

Hey Brennan, thanks for the contribution! Got a packed week but I'll try get around to this within a few days ^_^

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

Successfully merging this pull request may close these issues.

2 participants