There are crates which do a better job of providing a page allocator such as https://github.com/ezrosent/allocators-rs/tree/master/mmap-alloc
I have expressed a desire in the past for
memmap to offer an API specialized for page allocation, but the only thing I recall coming out of those discussions was that memmap would stick to just providing cross platform memory mapped files, which has absolutely nothing to do with page allocation (aside from using the same syscall on linux)
but I agree, that API does seem better for pure allocation usecases
Nothing realistic off the top of my head
actually I take that back. I think it's pretty common to have a file which you write to for a time, and then switch to be read-only
good idea
I assume linux will share physical memory for multiple mappings of the same file?
@danburkert I will be pretty busy this next few days, but should have some time to play around with this over the weekend.
Hey all! We could use a hand in
mio to get the Android build working again. It's containerised so you should only need docker. If you're familiar with the Android SDK that might help
@bobbo thanks for opening up the tracking issue for
num_cpus! I've posted them to This Week in Rust so they should show up in the next issue, but I don't think they'll last too long. Thanks again for running this evaluation :)
I need to open up some tracking issues for
semver. I'll leave it for a few days in case anyone has any last minute feedback then open them up. We can always flesh out some of the bigger things more in GitHub issues
@danburkert have you had a chance to give any more thought to the API changes necessary for memmap? @KodrAus suggested that it might be good to create an issue on the memmap Github indicating that a refactoring needs to be performed. I am more than happy to do this, but would like to get your thoughts first. Also, if there is anyway I can help feel free to let me know!
@bobbo yeh it has been a bit quiet recently. Hopefully we can get some attention on those bigger
semver issues. Thanks for taking on the privacy one! If you'd like to lead another evaluation please feel free to kick one off! All the crates in the WG doc should have go ahead from the author, but it's probably worth reaching out first
Alright, just cut a 0.6 release of memmap with the new API changes, and sent out a bunch of PRs to downstream crates. Other than code-reviews, I probably won't have much time to take on any other things with memmap for a while. I think it's getting in to pretty good shape, though
however, to be an “official” part of the blitz, the evaluation needs to be presented to the libs team and reach consensus there
in some cases there are some open design questions
but the process isn’t suited for really open-ended exploration
gfx-hal is in a non-trivial position here. I believe it's a foundational rust library that needs to be available to anyone. At the same time, it's not close to being stable now. Would the group consider having a preliminary look at it to give us early feedback on the stabilization path?
1) you could start an internals thread to get feedback on the library and talk about open issues, trying to suss out a direction
2) you could spin up something like WG-libs-rand, which is a working group specifically dedicated to resolving the open design and impl issues around the rand crate
@aturon ok. We'll greatly appreciate being mentioned in the newsletter. Our main gitter is https://gitter.im/gfx-rs/gfx , although I can create a specific room for blitz if you can see it appropriate. Thank you!