Refactor Memory API to use mmap() syscall. #13
Labels
No Label
bug
duplicate
enhancement
help wanted
invalid
question
wontfix
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Telodendria/Telodendria#13
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Instead of just being a simple wrapper over
malloc()
, we might consider usingmmap()
directly. This might make the memory API more flexible, although it adds a lot more complexity.Wanted to note down that while
mmap
is indeed POSIX, some exotic platforms' libc might not ship with it, so a way to keep with the "old" malloc-based method as a "second-tier citizen"(or maybe even something à la DOOM, with a large, preallocated area) for stranger platformsGood point. And honestly, this is kind of more wishful thinking for the time being, I might not ever actually get around to doing this. The current method is at no risk of going away any time soon.
That being said, if an OS doesn't have something specified in POSIX, Telodendria is under no obligation to support it. I'm specifically targeting POSIX; trying to beat an OS that isn't POSIX into submission isn't really one of the goals.
Do you have a an example of a system in mind that doesn't have
mmap()
?This is true.
The only example I could think of at the current moment to be totally frank are really small and hobbyist attempts at making a libc(which again, Telodendria doesn't really have to support those upstream), like this one.