Crates.io | winmmf |
lib.rs | winmmf |
version | |
source | src |
created_at | 2024-09-30 12:10:50.927738 |
updated_at | 2024-10-16 11:51:34.061853 |
description | A mostly safe Rust wrapper around Named Shared Memory on Windows. WIP |
homepage | https://skaye.blog/winmmf/overview |
repository | https://github.com/RivenSkaye/WinMMF-rs |
max_upload_size | |
id | 1391655 |
Cargo.toml error: | TOML parse error at line 19, column 1 | 19 | autolib = false | ^^^^^^^ unknown field `autolib`, expected one of `name`, `version`, `edition`, `authors`, `description`, `readme`, `license`, `repository`, `homepage`, `documentation`, `build`, `resolver`, `links`, `default-run`, `default_dash_run`, `rust-version`, `rust_dash_version`, `rust_version`, `license-file`, `license_dash_file`, `license_file`, `licenseFile`, `license_capital_file`, `forced-target`, `forced_dash_target`, `autobins`, `autotests`, `autoexamples`, `autobenches`, `publish`, `metadata`, `keywords`, `categories`, `exclude`, `include` |
size | 0 |
When working with Windows, there isn't a really ergonomic shm
or mmap
implementation that lets you share regions of memory across the application boundary easily. Instead the usual ways are calling back to localhost, (Named) Pipes, RPC, or Sockets (including the broken AF_UNIX
implementation). None of these are viable for low latency and/or large amounts of data being exchanged however, as they all use the networking stack and some of these don't even support communicating with multiple external processes. And if you don't need a message and sometimes you just need to move more data, or move it faster on the local system, than what these methods allow. Enter Named shared memory, the roundabout way of mapping a named region of memory backed by the pagefile!
This crate exists to support this IPC mechanism in Rust. With the power of microSEH to handle Structured Exception Hissy fits and some well thought out ways to make using this as safe as possible, it should be fine to use. I'm currently working on finding out how well this will run in a production environment, once some other challenges are solved causing issues in the environment it should run in.
This crate is currently in a state of baby steps. I've done some basic testing and it mostly works, but there's no full test suite yet. I'm also having some trouble figuring out what the best approach would be for this, as it'd require either multithreading and opening several handles to the same MMF, or permission elevation.
Contributors are always welcome. Even more so if they can help cover what's lacking here, such as implementing a full test suite and implementing more architectures.
[!TIP] The crate does not warrant expansive usage examples or scenario sketches of any kind. Most use cases will only ever use a very narrow API (by design) and those are all covered in the unit tests with the exception of
read_to_buff
. The difference withread
being that the second argument should be a&mut Vec<u8>
. You don't have to worry about the Vec's capacity either,read_to_buff
will just reserve more space if required!
Being able to support sharing memory accross the application boundary. This includes providing ergonomic interfaces for screeching at people before things break (lacking permissions for example) and making it possible for easily accessing the data one needs to pass into child processes to share mem their way. For now, this means one large block of memory.