Comments (11)
You're right that we weren't talking about the same thing originally, but I may be able to restructure what I want to do so that it fits in with what you're suggesting. My original plan was that I could have an arbitrarily large archive file, and multiple disjoint views on the file that are mmap
ed as disjoint &mut [u8]
slices. The idea was that different writers would update different portions of the file at the same time. But as you say, this could be very, very messy.
I'll work on restructuring my design, probably with lots of much smaller files. That will ensure that the file handles are to entirely separate objects, with at most on mmap
ed region from each file at a time. At least accessing different files is thread-safe!
from memmap2-rs.
#13 ?
from memmap2-rs.
https://docs.rs/memmap2/0.2.1/memmap2/struct.MmapMut.html#safety
from memmap2-rs.
I appreciate the blurb, but is there any way to give us slightly stronger guarantees? E.g., if we memory map disjoint regions of the same file are we guaranteed that they will never directly interfere with one another (I'm not worried about out of process behavior, just in process, with two completely different async tasks writing to disjoint regions of the same file)?
from memmap2-rs.
I'm not worried about out of process behavior
That's the problem. We cannot guarantee that.
from memmap2-rs.
Sure, I understand that. I have unrelated mechanisms that (should) protect against that kind of problem. However, I don't know if my using memmap on the same file handle within the same process, but on different threads and to disjoint regions of the file is by itself unsafe. Do you know if that action itself will cause UB?
from memmap2-rs.
Sadly, no idea. I'm using memmap in a very trivial way and I'm not aware of possible edge cases.
from memmap2-rs.
Got it. OK, I'll have to think up some other way to handle my use case then. Thank you for your quick replies!
from memmap2-rs.
However, I don't know if my using memmap on the same file handle within the same process, but on different threads and to disjoint regions of the file is by itself unsafe. Do you know if that action itself will cause UB?
A memory map provides you with an instance of &mut [u8]
. If you are able to ensure that only place in your code (and no other processes) create memory maps of the file in question, you should be able to perform the synchronisation based on that slice. (In this scenario, nothing anywhere else actually knows that the slice is backed by a memory map of a file. It is just virtual memory like any other memory.)
That said, mmap
itself is thread-safe (MT-Safe
in POSIX speech) (one of the reasons it is relatively slow to create a mapping even though using it is fast). If you are using read-only maps, it should not be an issue to create them concurrently. Read-write maps however seem like they could be problematic if they are not aligned to page size, i.e. if one underlying page is partially part of two maps.
from memmap2-rs.
A memory map provides you with an instance of &mut [u8]. If you are able to ensure that only place in your code (and no other processes) create memory maps of the file in question, you should be able to perform the synchronisation based on that slice. (In this scenario, nothing anywhere else actually knows that the slice is backed by a memory map of a file. It is just virtual memory like any other memory.)
Thank you @adamreichold, that's exactly what I needed to know! Within my own process space, I can guarantee that instances of &mut [u8]
never overlap any other slice anywhere, so as long as mmap
is thread-safe, then that should be taken care of.
Read-write maps however seem like they could be problematic if they are not aligned to page size, i.e. if one underlying page is partially part of two maps.
That is a harder nut for me to crack. My goal is write an extremely fast serializer/deserializer similar in spirit to abomonation, but which is somewhat safer to use, correctly deals with cycles in object graphs, and whose serialized contents can be passed around between different platforms which may have different page sizes. That is a long-winded way of saying that I can't easily align to any given page size, as what works on one platform may not work on another. Do you know if being misaligned would cause any correctness issues? I can figure out a way around the speed problem, as long as the result is always correct.
from memmap2-rs.
Within my own process space, I can guarantee that instances of &mut [u8] never overlap any other slice anywhere, so as long as mmap is thread-safe, then that should be taken care of.
I am not sure we are talking about the same thing? I was suggest to restructure things so that there is only one instance of the Mmap
type for each file and all code using this memory map really only uses &mut [u8]
and does not know that this slice was derived from a memory map at all. Hence whether Mmap
is Sync
does not even enter the picture as only byte slices would be passed between tasks/threads. (The idea is to avoid any question on the guarantees that mmap
provides by not using them at all. Whether you &mut [u8]
was created by fs::read
or Mmap
should not matter in this approach.)
Do you know if being misaligned would cause any correctness issues? I can figure out a way around the speed problem, as long as the result is always correct.
Sorry, but I really do not know and hence would work on the assumption that it does.
from memmap2-rs.
Related Issues (20)
- Migrate to `safer_owning_ref` HOT 1
- why does memmap2::Mmap::map need to be unsafe? HOT 4
- Implement AsRawFd, IntoRawFd, AsRawHandle, IntoRawHandle and Into<Stdio> for MMap HOT 2
- Composite memory maps currently impossible HOT 7
- mmap'd anon pages fail in io_uring IOSQE_BUFFER_SELECT usage HOT 2
- advise_writes_unsafely_to_part_of_map test fails on powerpc64le-unknown-linux-gnu HOT 2
- error[E0433]: failed to resolve: could not find `Advice` in `memmap2` HOT 1
- PermissionDenied, message: "Access is denied." at remove file after read on Github Action WIndows HOT 2
- Doesn't compile for freebsd HOT 3
- v0.9.2 build failed for android target. HOT 3
- Support for `MS_INVALIDATE`? HOT 8
- Mac osx support HOT 1
- Support `mremap(2)` HOT 1
- Mapping beyond 4GB offset if broken on 32 bit glibc (Linux) HOT 3
- Support multiple advice HOT 2
- Contributing a migration from rustix to libc HOT 9
- MSRV and edition HOT 5
- Merging changes with memmapix HOT 24
- memmap2 `advise` is unsound HOT 8
- Interest is supporting mbind HOT 10
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from memmap2-rs.