elast0ny / shared_memory Goto Github PK

https://github.com/elast0ny/shared_memory-rs/blob/b616fc40956dd7451dab88a7bb54e09d50bfee6e/src/lib.rs#L231-L238

As far as I can tell these are unpublished but those methods are not sound. The first return type, &[u8], requires that the range of bytes is immutable while the second, &mut [u8], requires that it is unique. Furthermore both require them to actually be initialized. Neither can be guaranteed for shared memory.

These methods would need to be unsafe but the requirements are almost impossible to validate. A somewhat better return type would be &UnsafeCell<[MaybeUninit<u8>]> which guarantees almost nothing about the contents except that the memory exists.

When two processes are trying to create a shared memory link file with the same path, a time of check time of use error can happen where both process 1 and 2 check if the file exists, then both proceed to creating the file.

If for example, process 1 creates the file first, process 2 will simply overwrite the file and not return any error leaving process 1 without a link file pointing to its mapping.

The process creating the link file will have to atomically check&create or return an error.

See #23 (comment)

The latest crates.io version 0.11.4 does no longer work because it still has a 0.* wildcard dependency on nix. Thus, cargo uses the latest available version, nix 0.22, which is not compatible with this crate without adjustments (see #68). The wildcard dependencies were fixed in January as part of #57, but this wasn't released to crates.io yet.

Is it possible?

Qemu ivshmem allows user mode processes to share memory across qemu VM boundaries and the host. This is especially useful because this allows resource intensive computations to be ran on the host and the results are directly accessible through regular memory accesses in the VM. Another use-case for this is running worker processes in separate VMs and sharing their results between themselves (across VM boundaries).

I have a prototype in C to do this already, not sure how complicated/possible it is to port it to mem_file.

As some user had mentionned on reddit. It would be nice if you could create shared memory where only the creator can write and other processes can only read. This would enable "safe" sharing with un-trusted processes.

This causes a stack overflow:

println!("{}", shared_memory::ShmemError::MapOpenFailed(0));

Running cargo expand on the quick_error! macro for ShmemError shows this

ShmemError::MapOpenFailed(ref err) => {
    let display_fn = |x: &ShmemError, f: &mut ::std::fmt::Formatter| {
        f.write_fmt(::core::fmt::Arguments::new_v1(
            &["", " : os error "],
            &match (&x, &err) {
                (arg0, arg1) => [
                    ::core::fmt::ArgumentV1::new(arg0, ::core::fmt::Display::fmt),
                    ::core::fmt::ArgumentV1::new(arg1, ::core::fmt::Display::fmt),
                ],
            },
        ))
    };
    display_fn(self, fmt)
}

which seems to contain an infinite recursion, the Display impl for ShmemError calls itself.

Hi I am trying to figure out how to handle a situation where in one process a shared memory link would be created then go out of scope with nothing being written to it. Which would then cause it to be removed from memory.

In parallel another process would be creating a shared memory link. It would see the link existed and fall into the caught error of Err(SharedMemError::LinkExists) => SharedMem::open_linked(link_path)?, At this point the first process has already removed the shared memory so when process two goes to open the link with that specified link path it is no longer there. This leads to the error of Error: MapOpenFailed(22).

Is there an easy solution to this problem?

I have tried to do something like this after the first match config.create()
Err(SharedMemError::LinkExists) => { match SharedMem::open_linked(link_path) { Ok(x) => x, Err(SharedMemError::MapOpenFailed(22)) => { config.create()? }, } }

The issue with this is that SharedMemConf doesn't implement the Copy trait. Which is there a specific reason as for why it cannot implement copy?

This crate could be converted to no_std as it mostly relies on OS specific system calls and only supports 2-3 main OSes. It shouldn't be too hard to rip out the existing std dependencies.

Unfortunately, the dependency i chose for file system locks seems to be broken on MacOS.

The race happens when process 1 creates a file that is supposed to contain the shared memory mapping unique ID but process 2 ends up reading the file before the ID is written by process 1...

I will have to either find a new file locking crate or be OK with not fully supporting MacOS for now.

At the moment, the number and kinds of locks and events is fixed when creating the shared memory. There are APIs (like channels) where it would be useful to be able to create these dynamically, allocating them into the regular shared memory rather than the metadata. Is this doable?

Android API 26 has support for shared memory, see:
Guides
Reference

As of now, the crate only supports a couple of locking mechanisms.

It would also be nice to have events/signaling. This is both supported on Windows/*nix

target：Use shared_memery to cache data for node multiple processes

my code

#[macro_use]
extern crate lazy_static;

extern crate neon;

extern crate shared_memory;

use neon::prelude::*;
use neon::register_module;
use shared_memory::*;
use std::collections::HashMap;
use std::ffi::{CStr, CString};
use std::sync::Mutex;

#[derive(SharedMemCast)]
struct ShmemStructCache {
  num_slaves: u32,
  message: [u8; 256],
}

static GLOBAL_LOCK_ID: usize = 0;

fn create_open_mem(operator: f64, object: String) -> Result<String, SharedMemError> {
  let shmem = match SharedMem::create_linked("shared_mem.link", LockType::Mutex, 4096) {
    Ok(v) => v,
    Err(SharedMemError::LinkExists) => SharedMem::open_linked("shared_mem.link")?,
    Err(e) => return Err(e),
  };

  if shmem.num_locks() != 1 {
    return Ok(String::from("Expected to only have 1 lock in shared mapping !"));
  }

  if operator == 0 as f64 {
    set_cache(shmem, object)
  } else {
    get_cache(shmem)
  }
}

fn set_cache(mut shmem: SharedMem, object: String) -> Result<String, SharedMemError> {
  {
    let mut shared_state = shmem.wlock::<ShmemStructCache>(GLOBAL_LOCK_ID)?;
    let set_string: CString = CString::new(object.as_str()).unwrap();
    shared_state.message[0..set_string.to_bytes_with_nul().len()]
      .copy_from_slice(set_string.to_bytes_with_nul());
  }
  Ok("".to_owned())
}

fn get_cache(mut shmem: SharedMem) -> Result<String, SharedMemError> {
  let mut result = "";
  {
    let shared_state = shmem.rlock::<ShmemStructCache>(GLOBAL_LOCK_ID)?;
    let shmem_str: &CStr = unsafe { CStr::from_ptr(shared_state.message.as_ptr() as *mut i8) };
    result = shmem_str.to_str().unwrap();
  }

  Ok(result.to_owned())
}


fn cache_opeator(mut cx: FunctionContext) -> JsResult<JsString> {
  let operator = cx.argument::<JsNumber>(0)?.value();
  let set_value = cx.argument::<JsString>(1)?.value();
  match create_open_mem(operator, set_value) {
    Ok(v) => Ok(cx.string(v)),
    Err(e) => Ok(cx.string("error")),
  }
}

register_module!(mut m, {
  m.export_function("opeator", cache_opeator)?;
  Ok(())
});

js code

var addon = require('../native');
const result = addon.opeator(1,new Date().getTime().toString()); //get


if (result) {
    let last = addon.opeator(1,""); //get
    addon.opeator(1,last + result + new Date().getTime().toString()) //set 
} else {
    addon.opeator(0,new Date().getTime().toString());// set
}

run & what's wrong

pm2 start lib/index.js -i 2 --name cache
i cant set data

Thank you for your answers 😋

when trying to compile shared_memory 0.11.1 on Windows 10 I get this error.

error[E0432]: unresolved imports `winapi::shared::winerror`, `winapi::um::handleapi`, `winapi::um::winbase`
  --> C:\Users\domen\.cargo\registry\src\github.com-1ecc6299db9ec823\shared_memory-0.11.1\src\windows.rs:4:9
   |
4  |         winerror::ERROR_ALREADY_EXISTS,
   |         ^^^^^^^^ could not find `winerror` in `shared`
...
8  |         handleapi::{CloseHandle, INVALID_HANDLE_VALUE},
   |         ^^^^^^^^^ could not find `handleapi` in `um`
9  |         memoryapi::{MapViewOfFile, UnmapViewOfFile, VirtualQuery, FILE_MAP_READ, FILE_MAP_WRITE},
10 |         winbase::{CreateFileMappingA, OpenFileMappingA},
   |         ^^^^^^^ could not find `winbase` in `um`

Other information:
windows 10 (build 17763)
rustup 1.21.1 (7832b2ebe 2019-12-20)
cargo 1.45.0-nightly (cb06cb269 2020-05-08)
rustc 1.45.0-nightly (a74d1862d 2020-05-14)

With the new procedural macros in 1.30, I think it would now be possible to have something like :

#[derive(SharedMemCast)]
struct MyStruct {
    //...
}

The procedural macro would recursively ensure that all the types in MyStruct are safe to be used in shared memory...

This would remove the need for SharedMemCast

Currently, the crate is quite painful to use because it returns Box'ed strings as errors.

At the bare minimum, the crate should at least have an error enum that implements std::fmt::Display and such.

Hello

As far as I can see, Shmem::set_owner method does not affect the behavior of unix::MapData, as MapData::owner depends only on called function (whether it is create_mapping or open_mapping).

Using references of a specific type makes the API unnecessarily inconvenient to use.

SharedMem::open_linked, for example, would be better served as AsRef<OsStr>, which would allow calling it like SharedMem::open_linked("whatever", ...) instead of SharedMem::create_linked(OsStr::new("whatever"), ...), since str implements AsRef for OsStr

Basically everything from #15 would be more ergonomic if it used AsRef over raw references.

See also the api guidelines on this.

https://github.com/elast0ny/shared_memory-rs/blob/749f11db3324afc41d67a8229bbbd059856494a6/src/windows.rs#L63

This is missing a right-shift.

Seems unintentional but in rare circumstances the unique ID can contain spaces:

format!("/shmem_rs_{:16X}", rand::thread_rng().gen::<u64>()),

Eg:

/shmem_rs_ B4B25F3A9866723

Hello @elast0ny and thanks for such a useful library!

At the title stands, currently the WriteLockable::wlock methods takes self by a mutable (unique) reference, which I believe doesn't make a lot of sense: since the unique-mutalbe-borrow-check is performed in the runtime, the mutability requirement could be lifted.

While this inconvenience could be easily circumvented by opening the same shared memory area twice, it is still a circumvention and adds a seemingly unnecessary boilerplate.

My usecase for that is to access distinct indices simultaneously.

Do you think we could have it solved?

Thanks!

As suggested by @llogiq , mem_file would probably benefit from the features provided by https://travis-ci.org/

I will have to set up compilation on the supported targets at a minimum and maybe try to see how testing could be implemented.

Testing might prove to be a bit tricky since mem_file is a library aimed for multi-process environments and it sounds like a headache to do automated testing for that. Issues that come to mind:

• Granted that you can launch multiple separate processes in a single cargo test, how do you validate:
  -Memory is actually shared
  -Locking mechanism work properly (the two process cant both hold a mutex for example)
  -Things are getting cleaned up/closed properly after a non-crashing/non-frozen run

• In case of error for any of these testcases, your testing framework might have to deal with crashes processes, frozen processes waiting forever on locks, etc.. on a per-OS basis.

Unfortunately OSX does not implement "pthread_mutex_timedlock".

This means that regular pthread_cond with a mutex wont be able to have proper timeouts set when trying to acquire the mutex...

At least SharedMemRaw::create(), ::open() internally just takes a reference of the string, so could use a &str instead (to allow no allocations).

Similarly SharedMemConf::set_link_path() takes &PathBuf and that could just be a &Path for the same reason, and the same in SharedMem::create_linked() and SharedMem::open_linked().

Relatedly, get_link_path() and get_os_path() and similar should probably return references to the unowned types (str, Path) instead.

And it seems that the OS path related API should actually use OsStr / OsString instead, AFAIU it might not be a valid UTF8 string (on UNIX systems at least).

I have two processes, and don't know which of them will attempt to open the shared memory first. When using CreateFileMapping on windows, this is fine, because the semantics of this function are to attempt to either create a new object or return an existing one. So whichever program makes it there first creates the mapping, and the other opens it.

However, in this crate I only see a function for creating a new mapping (ShmemConf::create), and another function for opening an existing mapping (ShmemConf::open).

How can I recover the original semantics of CreateFileMapping?

If a unique ID is not defined in SharedMemConf, a random one is generated using this code:

let unique_id: String = match self.wanted_os_path {
    Some(ref s) => s.clone(),
    None => {
        format!("shmem_rs_{:16X}", rand::thread_rng().gen::<u64>())
    },
};

However, it looks like the generated name doesn't work on all supported platforms. I've got a simple program that uses this library, and it works on Linux but fails on FreeBSD with the following error:

shm_open() failed with :\nErr(Sys(EINVAL))

After looking at shm_open man pages, I noticed that FreeBSD has an extra restriction: the name parameter must begin with a slash. The man page on my local Linux system also suggests that a slash is required for portability.

FreeBSD:

The following errors are defined for shm_open():
[EINVAL] The path does not begin with a slash (`/') character.

Linux:

For portable use, a shared memory object should be identified by a name of the form /somename; that is, a null-terminated string of up to NAME_MAX (i.e., 255) characters consisting of an initial slash, followed by one or more characters, none of which are slashes.

And POSIX:

The name argument conforms to the construction rules for a pathname, except that the interpretation of characters other than the leading character in name is implementation-defined, and that the length limits for the name argument are implementation-defined and need not be the same as the pathname limits {PATH_MAX} and {NAME_MAX}. If name begins with the character, then processes calling shm_open() with the same value of name refer to the same shared memory object, as long as that name has not been removed. If name does not begin with the character, the effect is implementation-defined.

It would be useful for users to be able to choose the locking mechanism when creating the shared memory mapping.

Use case : Certain types of locks might be better suited for specific applications and scenarios (ie: Rwlock is more expensive to acquire but might be better suited for multiple readers / 1 writer).

Every platform should probably at least implement Mutex style locking on shared memory.

The ReadLockGuard and WriteLockGuard types implement Deref and DerefMut respectively, but it is not obvious this is safe. For example, by locking the same area of memory at different types, I can get a &usize and an &AtomicUsize which alias, then storing into the &AtomicUsize causes the &usize to become UB.

mem_file should support opening "raw" shared memory.

Right now, create() and open() both use link files on disk and metadata in the shared mapping to make things run smoothly but users of this lib should also be able to open/create shared memory mappings

mem_file could implement a create_raw() and open_raw() that would simply create/open the specified mappings with no locking or metadata involved.

For the new API, it would be nice if users could create as many locks/events as they want for their shared memory.

For example, one might want to have 2 events for a single mapping which could allow you to do things like send/recv between two processes.

I'm thinking of something like :

//Prepare the mapping
my_mem = SharedMem::new("some_path", 4096).unwrap()
    .add_lock(LockType::Mutex, 0, 2047) // Lock to give you access to the first 2kb
    .add_lock(LockType::Mutex, 2048, -1) // Lock that gives access to the last 2kb
    .add_event();

//Create the mapping with all the requested features
my_mem.create().unwrap();

my_mem.wait(0); // wait on the first event
my_mem.rlock(1); // acquire lock on the last 2kb

On rust 1.25 cargo test emitted these warnings:

   Doc-tests shared_memory
WARNING: src/lib.rs -  (line 5) Code block is not currently run as a test, but will in future versions of rustdoc. Please ensure this code block is a runnable test, or use the `ignore` directive.
WARNING: src/lib.rs -  (line 19) Code block is not currently run as a test, but will in future versions of rustdoc. Please ensure this code block is a runnable test, or use the `ignore` directive.
WARNING: src/locking.rs - locking::SharedMemLockable::rlock (line 56) Code block is not currently run as a test, but will in future versions of rustdoc. Please ensure this code block is a runnable test, or use the `ignore` directive.
WARNING: src/locking.rs - locking::SharedMemLockable::rlock_as_slice (line 69) Code block is not currently run as a test, but will in future versions of rustdoc. Please ensure this code block is a runnable test, or use the `ignore` directive.
WARNING: src/locking.rs - locking::SharedMemLockable::wlock_as_slice (line 94) Code block is not currently run as a test, but will in future versions of rustdoc. Please ensure this code block is a runnable test, or use the `ignore` directive.
WARNING: src/lib.rs - SharedMem<'a>::open (line 138) Code block is not currently run as a test, but will in future versions of rustdoc. Please ensure this code block is a runnable test, or use the `ignore` directive.
WARNING: src/lib.rs - SharedMemCast (line 273) Code block is not currently run as a test, but will in future versions of rustdoc. Please ensure this code block is a runnable test, or use the `ignore` directive.

After updating to rust 1.26 cargo test now fails with these errors:

   Doc-tests shared_memory

running 9 tests
test src/lib.rs -  (line 19) ... FAILED
test src/lib.rs -  (line 5) ... FAILED
test src/lib.rs - SharedMemCast (line 273) ... FAILED
test src/lib.rs - SharedMem<'a>::open (line 138) ... FAILED
test src/locking.rs - locking::SharedMemLockable::wlock_as_slice (line 94) ... FAILED
test src/lib.rs - SharedMem<'a>::create (line 85) ... ok
test src/locking.rs - locking::SharedMemLockable::rlock (line 56) ... ok
test src/locking.rs - locking::SharedMemLockable::rlock_as_slice (line 69) ... ok
test src/locking.rs - locking::SharedMemLockable::wlock (line 81) ... ok

failures:

---- src/lib.rs -  (line 19) stdout ----
	error: expected one of `.`, `?`, `{`, or an operator, found `;`
 --> src/lib.rs:20:95
  |
3 | let mut my_shmem: SharedMem = match SharedMem::open(PathBuf::from("shared_mem.link")).unwrap();
  |                               ----- help: try removing this `match`                           ^ expected one of `.`, `?`, `{`, or an operator here

thread 'rustc' panicked at 'couldn't compile the test', librustdoc/test.rs:306:13
note: Run with `RUST_BACKTRACE=1` for a backtrace.

---- src/lib.rs -  (line 5) stdout ----
	error: expected one of `,`, `.`, `?`, or an operator, found `LockType`
 --> src/lib.rs:7:88
  |
4 | let mut my_shmem: SharedMem = match SharedMem::create(PathBuf::from("shared_mem.link") LockType::Mutex, 4096).unwrap();
  |                                                                                        ^^^^^^^^ expected one of `,`, `.`, `?`, or an operator here

error: expected one of `.`, `?`, `{`, or an operator, found `;`
 --> src/lib.rs:7:119
  |
4 | let mut my_shmem: SharedMem = match SharedMem::create(PathBuf::from("shared_mem.link") LockType::Mutex, 4096).unwrap();
  |                               ----- help: try removing this `match`                                                   ^ expected one of `.`, `?`, `{`, or an operator here

thread 'rustc' panicked at 'couldn't compile the test', librustdoc/test.rs:306:13

---- src/lib.rs - SharedMemCast (line 273) stdout ----
	error: expected type, found `...`
  --> src/lib.rs:281:2
   |
10 | <...>
   |  ^^^

error[E0405]: cannot find trait `SharedMemCast` in this scope
 --> src/lib.rs:279:13
  |
8 | unsafe impl SharedMemCast for SharedState {}
  |             ^^^^^^^^^^^^^ not found in this scope

thread 'rustc' panicked at 'couldn't compile the test', librustdoc/test.rs:306:13

---- src/lib.rs - SharedMem<'a>::open (line 138) stdout ----
	error[E0433]: failed to resolve. Use of undeclared type or module `PathBuf`
 --> src/lib.rs:141:53
  |
6 | let mut my_shmem: SharedMem = match SharedMem::open(PathBuf::from("shared_mem.link")) {
  |                                                     ^^^^^^^ Use of undeclared type or module `PathBuf`

thread 'rustc' panicked at 'couldn't compile the test', librustdoc/test.rs:306:13

---- src/locking.rs - locking::SharedMemLockable::wlock_as_slice (line 94) stdout ----
	error[E0596]: cannot borrow immutable local variable `write_buf` as mutable
 --> src/locking.rs:100:1
  |
8 | let write_buf = my_shmem.wlock_as_slice::<u8>().unwrap();
  |     --------- consider changing this to `mut write_buf`
9 | write_buf[0] = 0x1;
  | ^^^^^^^^^ cannot borrow mutably

thread 'rustc' panicked at 'couldn't compile the test', librustdoc/test.rs:306:13


failures:
    src/lib.rs -  (line 19)
    src/lib.rs -  (line 5)
    src/lib.rs - SharedMem<'a>::open (line 138)
    src/lib.rs - SharedMemCast (line 273)
    src/locking.rs - locking::SharedMemLockable::wlock_as_slice (line 94)

test result: FAILED. 4 passed; 5 failed; 0 ignored; 0 measured; 0 filtered out

I am not able to use shared_memory lib and systemd_journal_logger lib together when I run binary file without debug symbols

For example

`use log::LevelFilter;

fn main() {
  systemd_journal_logger::init().unwrap();

  log::set_max_level( LevelFilter::Debug);

  log::warn!("A warning.");
  log::error!("An error");
}    `

And this dependencies

`[dependencies]
serde =  { version = "1.0", features = ["derive"] }
serde_json = "1.0"
log = "=0.4.14"
systemd-journal-logger = "=0.3.1"

everything works perfectly when running ./target/release/xyz

but if I include shared_memory It stops working

I checked in sm source code that implements a log crate, why dont use standard log api implementation ?|
thanks

https://github.com/elast0ny/shared_memory-rs/blob/749f11db3324afc41d67a8229bbbd059856494a6/src/windows.rs#L65-L73

This is using the ANSI API on string data that is not ANSI-encoded. It should be using the wide APIs, using the standard library utils for conversion to UTF-16.

I can make up a pull request for this tomorrow.

(aside: that call to .as_ptr() on a temporary is terrifying and---while correct---it depends on delicate aspects of drop order that people seldom talk about. I can't imagine why anyone would choose to silence the lint when they could easily add a binding for the temporary in just as many characters...)

Also pointed out by Glandium : https://www.reddit.com/r/rust/comments/8dacce/shared_memory_wrapper_for_rust/dxlt5tj.

My locks in the linux implementation should have the PTHREAD_PROCESS_SHARED attribute so that they can safely be shared across processes.

Library shouldn't be used on Linux until this is fixed...

Can you provide a simple example that does not involve other packages?
For example, save the string-"asdfg" to the shared memory named "T1".
Yes, this is also my requirement, but I have read the two examples for a long time and don't know how to achieve my goal.

Trying to open shared memory of third-party application that is created only as named object.

ShmemConf::new().os_id("TestNamedObject").open()

fails with OS error 2 (No such file or directory) because open_mapping tries to access non-existent %TEMP%\shared-memory-rs\TestNamedObject.
It worked correctly in 0.11.

There is something wrong with the latest version of this crate https://crates.io/crates/shared_memory/0.12.2: it requires log crate, have

default = ["log/release_max_level_off"]

and does not match with version in this repository.

As pointed oit by Glandium : https://www.reddit.com/r/rust/comments/8dacce/shared_memory_wrapper_for_rust/dxlt5tj

Slim RW locks in Windows are actualy just pointers that also rely on per-process data (which cannot be shared through the shared memory).

Until this is fixed, mem_file on Windows doesn't implement locking properly.

People who implement this trait should be aware of the implications

Hi there! I've been playing with your crate as a way of improving the perf and API of Servo's inter-process communication, and came up with https://github.com/asajeffrey/shared-data

At the moment this is just basic shared data structures, e.g. boxes, vectors, and ref-counted pointers, but it's a start!

At the moment, there seems to be a pretty clean line between what shared_memory provides (access to shared memory as *mut u8) and what shared-data does (higher level safe APIs). Perhaps there are ideas that should be moved from one to the other? The only thing that's a bit funny right now is that SharedMemCast is in shared_memory and SharedMemRef (types you can take a reference to in shared memory) is in shared-data.

When first creating the shmem file, the application will crash with a segmentation fault on this line:

let (evt, used_bytes) = unsafe { Event::new(shmem.as_ptr(), true)? };

Output:

Getting the shared memory mapping
Creating event in shared memory
Segmentation fault (core dumped)

Once the file is created, i.e. shmem.is_owner() is false, then the application runs fine.

Extra info:

• Running on Arch Linux, kernel: 5.6.10-arch1-1
• rustc 1.43.0 (stable)
• Ran both with cargo, and without. Segfaults with both

I went back to the 0.10.0 commit: 651f889, and ran the basic example, which worked fine.

Hi,
I'm using this library to allocate a portion of shared memory where data may differ wildly in size.
Does the library have any mechanism for resizing previously allocated shared memory?

I've been trying out shared_memory and it seems to working as expect on Mac, but when running inside a docker container based off rust:1.38 my program invariable crashes with the error message "Bus error (core dumped)" when calling SharedMem::create(LockType::RwLock, 1024).

https://docs.rs/shared_memory/0.10.0/shared_memory/

You could put a relative link?

Cargo version: 1.53.0 (also tried with 1.55.0-nightly)
Rustc version: 1.53.0 (also tried with 1.55.0-nightly)
Crate version: 0.11.4

When it compile the crate it throw these errors:

error[E0164]: expected tuple struct or tuple variant, found associated function `nix::Error::Sys`
  --> /home/zacharie/.cargo/registry/src/github.com-1ecc6299db9ec823/shared_memory-0.11.4/src/unix.rs:87:13
   |
87 |         Err(nix::Error::Sys(Errno::EEXIST)) => return Err(ShmemError::MappingIdExists),
   |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `fn` calls are not allowed in patterns
   |
   = help: for more information, visit https://doc.rust-lang.org/book/ch18-00-patterns.html

error[E0164]: expected tuple struct or tuple variant, found associated function `nix::Error::Sys`
  --> /home/zacharie/.cargo/registry/src/github.com-1ecc6299db9ec823/shared_memory-0.11.4/src/unix.rs:88:13
   |
88 |         Err(nix::Error::Sys(e)) => return Err(ShmemError::MapCreateFailed(e as u32)),
   |             ^^^^^^^^^^^^^^^^^^ `fn` calls are not allowed in patterns
   |
   = help: for more information, visit https://doc.rust-lang.org/book/ch18-00-patterns.html

error[E0164]: expected tuple struct or tuple variant, found associated function `nix::Error::Sys`
   --> /home/zacharie/.cargo/registry/src/github.com-1ecc6299db9ec823/shared_memory-0.11.4/src/unix.rs:103:13
    |
103 |         Err(nix::Error::Sys(e)) => return Err(ShmemError::UnknownOsError(e as u32)),
    |             ^^^^^^^^^^^^^^^^^^ `fn` calls are not allowed in patterns
    |
    = help: for more information, visit https://doc.rust-lang.org/book/ch18-00-patterns.html

error[E0164]: expected tuple struct or tuple variant, found associated function `nix::Error::Sys`
   --> /home/zacharie/.cargo/registry/src/github.com-1ecc6299db9ec823/shared_memory-0.11.4/src/unix.rs:119:13
    |
119 |         Err(nix::Error::Sys(e)) => return Err(ShmemError::MapCreateFailed(e as u32)),
    |             ^^^^^^^^^^^^^^^^^^ `fn` calls are not allowed in patterns
    |
    = help: for more information, visit https://doc.rust-lang.org/book/ch18-00-patterns.html

error[E0164]: expected tuple struct or tuple variant, found associated function `nix::Error::Sys`
   --> /home/zacharie/.cargo/registry/src/github.com-1ecc6299db9ec823/shared_memory-0.11.4/src/unix.rs:135:13
    |
135 |         Err(nix::Error::Sys(e)) => return Err(ShmemError::MapOpenFailed(e as u32)),
    |             ^^^^^^^^^^^^^^^^^^ `fn` calls are not allowed in patterns
    |
    = help: for more information, visit https://doc.rust-lang.org/book/ch18-00-patterns.html

error[E0164]: expected tuple struct or tuple variant, found associated function `nix::Error::Sys`
   --> /home/zacharie/.cargo/registry/src/github.com-1ecc6299db9ec823/shared_memory-0.11.4/src/unix.rs:150:13
    |
150 |         Err(nix::Error::Sys(e)) => return Err(ShmemError::MapOpenFailed(e as u32)),
    |             ^^^^^^^^^^^^^^^^^^ `fn` calls are not allowed in patterns
    |
    = help: for more information, visit https://doc.rust-lang.org/book/ch18-00-patterns.html

error[E0164]: expected tuple struct or tuple variant, found associated function `nix::Error::Sys`
   --> /home/zacharie/.cargo/registry/src/github.com-1ecc6299db9ec823/shared_memory-0.11.4/src/unix.rs:166:13
    |
166 |         Err(nix::Error::Sys(e)) => return Err(ShmemError::MapOpenFailed(e as u32)),
    |             ^^^^^^^^^^^^^^^^^^ `fn` calls are not allowed in patterns
    |
    = help: for more information, visit https://doc.rust-lang.org/book/ch18-00-patterns.html

error: aborting due to 7 previous errors

Hi,
This is an awesome project, yet it has not supported Android. Is there have a plan to work on that.

One of the requirements for bool is that it only has the values 0x00 and 0x01, so there is a possible safety issue around having bool implement SharedMemCast.

Hi,

Just to let you know, when switching to edition = "2021" in Cargo.toml, you should have bumped to 0.13.0 rather than 0.12.1, as shared_memory now breaks building for projects that depend (even transitively) on 0.12.0 when they run cargo update.

I think you can still fix that, by re-publishing as 0.13.0, and going on crates.io to yank 0.12.1

I detected the issue when running cargo update on a lib that had a transitive dependency on 0.12.0, if anyone sees this issue because they ran into something similar, quickest fix is to add shared_memory = "=0.12.0" to your deps, then run cargo update again.

Sorry, I seem to pester you quite a bit on these publishing matters, let me know if you try the yanking thing :)