-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
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
Comments for "https://os.phil-opp.com/heap-allocation/" #627
Comments
Thank you I was waiting this part ! |
Hey Philipp, thank you for the great post ( as always ✌️ ) I wanted to note that I think now it's possible to move the allocator to its own module and out of Can't wait for your next tutorial! |
@phil-opp As @shakram02 noted, rust-lang/rust#62735 now makes it possible to define the global allocator in a submodule. |
@shakram02 @toothbrush7777777 Thank you for reporting this and sorry for the late reply. I created #714 to move the Edit: Blog update in #715. |
The comment in the first code block in https://os.phil-opp.com/heap-allocation/#the-global-allocator-attribute should be |
@Menschenkindlein We recently moved the definition to the |
I guess it doesn't need |
Ah, good catch! Fixed in #728. |
How do you handle memory allocation failure gracefully in here ? (If my users starts forkbombing I’d like to avoid crashing the kernel and instead tell the user nope, your fork is a spoon) |
Currently the only way is to use the Alternatively, you could create your own |
Going down the rabbit hole in stumbled onto https://github.com/vcombey/fallible_collections not sure if other such crate exist, but this looks like a reasonable thing to use, until hopefully the original alloc crate decides on how to play nice with people who need to handle memory allocation errors. (The ability to have the allocator specify an Error type with the default being ! would imho be very nice) |
Looks useful!
I'm not aware of any proposals to change the global allocator, but there is the allocators working group that works on making collections parametrizable over the separate |
Hello. First, thank you for this amazing tutorial. I really enjoy it. I do have a build error when using the linked-list-allocator:
It seems that |
@n-osborne Thanks! The |
@phil-opp Thanks, it works like a charm. |
Hi phil-oop, I'm really enjoy your posts, and I have a question: Why alloc method in GlobalAlloc trait returns a mut pointer which type is u8, not usize? I think that data type u8 can not represent a full memory address in the machine. |
@imaginezz |
@imaginezz A |
Yes, it is! *u8 is the pointer to u8 data type like C. Thank you @toothbrush7777777 @bjorn3 very much! |
The tests in unsafe impl GlobalAlloc for Locked<BumpAllocator> {
unsafe fn alloc(&self, layout: Layout) -> *mut u8 {
self.lock().heap_start as *mut u8
}
unsafe fn dealloc(&self, _ptr: *mut u8, _layout: Layout) {
}
} Change let heap_value1 = Box::new(41);
let heap_value2 = Box::new(13);
assert_eq!(*heap_value1, 41);
assert_eq!(*heap_value2, 13); |
In your previous post you say:
However, the code still appears in this and future repos. Was this intentional? |
Thanks for the great tutorials! I am wanting to expand, and was thinking about creating a Or maybe ideas on how to expand on these posts? Challenges? Thanks! |
You should read https://os.phil-opp.com/async-await/ for an example. |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
This is a general purpose comment thread for the Heap Allocation post.
The text was updated successfully, but these errors were encountered: