Skip to content

On Windows the .size ShmemConf parameter is not respected #107

@3tilley

Description

@3tilley

Hello,

On linux if I ask to open a piece of Memory created somewhere else with a size, that size is the size of the buffer returned. On Windows if I do this (for a small buffer) I get 4096 - which I assume is the default smallest size for a piece of Windows shared memory. This means that the producer thinks it has buffer len x, while the consumer thinks it's working with buffer len 4096 (for a small buffer).

I think instead of using MEMORY_BASIC_INFORMATION.RegionSize the size from the opts should be taken, do you agree?

I've updated a test here to demonstrate this.

$ cargo test
   Compiling shared_memory v0.12.5 (C:\Users\Max\Documents\GitHub\shared_memory)
    Finished test [unoptimized + debuginfo] target(s) in 0.66s
     Running unittests src\lib.rs (target\debug\deps\shared_memory-baddeea1e8dc4909.exe)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\general.rs (target\debug\deps\general-356fc0d2e34d7138.exe)

running 5 tests
test share_data ... FAILED
test create_new ... ok
test open_os_id ... ok
test create_with_flink ... ok
test open_flink ... ok

failures:

---- share_data stdout ----
thread 'share_data' panicked at tests\general.rs:109:5:
assertion `left == right` failed
  left: 4
 right: 4096
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace


failures:
    share_data

test result: FAILED. 4 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.01s

error: test failed, to rerun pass `--test general`

Would you be happy for me to make this change?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions