Create a cross-platform shared-memory region about rust-cookbook HOT 9 CLOSED

Can you give more details why a fork should be used instead of executing separate binaries?

Due to two facts:

• because memmap crate not offering any way to create a named shared memory region (like shm_open). All it provides is a way to mmap a file or create an anonymous memory mapped region. First not being suitable for robust ipc and the second being reachable only from the creating process and it's children
• skeptic test runner not supporting orchestrating multi file/binary tests ;)

from rust-cookbook.

Any idea how such example would look like?

The canonical example would normally utilize fork to spawn a child process and communicate via mmap.

import mmap
import os

mm = mmap.mmap(-1, 13)
mm.write("Hello world!")

pid = os.fork()
if pid == 0:  # In a child process
    mm.seek(0)
    print mm.readline()
    mm.close()

But in Rust we do not have a stable fork API (the nix crate provides such functionality but it is not cross platform which defeats the purpose of "cross-platform" part in this example).

from rust-cookbook.

The canonical example would normally utilize fork to spawn a child process

Can you give more details why a fork should be used instead of executing separate binaries?

from rust-cookbook.

I'm interested in working on this and would like to claim it. Which platforms should be supported?

from rust-cookbook.

Hi @steveej, thanks for taking an interest.

Which platforms should be supported?

Its supposed to be cross platforms so at least all of rust tier 1 platforms

Please note that at this moment the example is not well defined (as not clear how should it be implemented to be both cross platform and idiomatic) so please post the implementation idea before starting to work on it so you'll not lose time.

from rust-cookbook.

@budziq

because memmap crate not offering any way to create a named shared memory region (like shm_open).

I wonder why that was left out. Maybe it should just be added so this example becomes possible.

All it provides is a way to mmap a file or create an anonymous memory mapped region.
First not being suitable for robust ipc

Would you mind to elaborate on this statement?

from rust-cookbook.

I wonder why that was left out.

Well we can always ask on their bugtracker ;) Possibly the semantics differ between windows and unix enough to make providing common and ergonomic api a pain.

Would you mind to elaborate on this statement?

On some systems trying to do ipc on standard memory mapped file would be no better than doing ipc on normal file read/write operations to the filesystem, on the other hand boost interprocess fallsback to shmem emulation via mapped fs files if there is no support for shared memory objects but this is hidden as an implementation detail and I feel that this would not be something we would like to teach our readers as a go-to solution.

It would be great to hear authors thoughts on the matter. Ping @danburkert :)

from rust-cookbook.

memmap is, to date, just a wrapper around mmap and the closest corresponding Windows APIs. We had a PR at one point to add shared memory support, but it never landed. I'm lukewarm on expanding the scope to include shared memory; unless it can be done in a minimally invasive way I think it would be better in a dedicated crate.

from rust-cookbook.

Thanks a lot for your thoughts! I think that it's best to just close this issue as it is not cleanly implementable with current crates ecosystem.

from rust-cookbook.