[9fans] POSIX shared memory (shm_open)

[9fans] POSIX shared memory (shm_open)

[Lassi Kortela]

Hello,

Can the POSIX shared memory API be emulated on Plan 9 with reasonable
effort? I didn't find any mention of 'shm_open' in Plan 9 source.

To recap, the API works as follows:

- shm_open(path) to open or create an shm object, get a file descriptor
- shm_unlink(path) to remove the shm object from the path namespace
- ftruncate(fd) to actually allocate n bytes for the shm object
- fstat(fd) returns the size of the object in the st_size field
- mmap(fd) to get a pointer to use the shared memory

The shm fd works like other Unix fds (can be sent to an unrelated
process over a Unix-domain socket, persists over fork(), and can persist
over exec() if the close-on-exec flag is cleared). The kernel garbage
collects the shm object after the last fd pointing to it is closed.

I made the shim <https://github.com/lassik/shm_open_anon> to provide a
"shm_open() without a pathname" on various Unix flavors. I'm wondering
if Plan 9 support could be easily added.

I should mention that I have never used Plan 9, just read some of the
source and documentation.

Regards,
Lassi

Re: [9fans] POSIX shared memory (shm_open)

[Ori Bernstein]

On Wed, 24 Apr 2019 18:22:35 +0300, Lassi Kortela <lassi@lassi.io> wrote:

> Hello,
>
> Can the POSIX shared memory API be emulated on Plan 9 with reasonable
> effort? I didn't find any mention of 'shm_open' in Plan 9 source.

It's almost certainly an intentional omission.

What problem are you trying to solve with it?

> To recap, the API works as follows:
>
> - shm_open(path) to open or create an shm object, get a file descriptor
> - shm_unlink(path) to remove the shm object from the path namespace
> - ftruncate(fd) to actually allocate n bytes for the shm object
> - fstat(fd) returns the size of the object in the st_size field
> - mmap(fd) to get a pointer to use the shared memory

With enough effort, it's certainly possible, to do what you want, but I
predict it will either fit poorly into plan 9, or it will perform poorly.
It'sl likely to end up in a state where it's a combination of both.

Why will it fit poorly into plan 9? Because plan 9 is a distributed system,
and it's common practice to run programs on different systems sharing the same
namespace -- essentially, assembling a computing environment from multiple
computers.

In that kind of environment, programs aren't even aware of which machines
resources they're accessing: it's just transparent. So, when you put a mutex
into shared memory, for example, how is it supposed to work when the shared
memory is coming from another machine?

Assuming that you have an approach for that in mind (including, possibly,
ignoring it and making porgrams break), the plan 9 memory management system is
designed with the assumption that only a small number of contiguous, disjoint
regions (segments) will be attached to a program. Typical programs have 4.

If you still want to implement it, start by reading the code for segattach.
You can proably put together a hacky version that breaks the distributed parts
of the system and scales poorly with the number of shm regions fairly quickly.
Making it good is harder.

Either way, if you decide to experiment, I'd be interested in seeing what you
write.

--
    Ori Bernstein

Re: [9fans] POSIX shared memory (shm_open)

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 1347 bytes --]

There's some support for sharing memory segments in segattach(2) and
between unrelated processes with segment(3).

On Wed, 24 Apr 2019 at 16:23, Lassi Kortela <lassi@lassi.io> wrote:

> Hello,
>
> Can the POSIX shared memory API be emulated on Plan 9 with reasonable
> effort? I didn't find any mention of 'shm_open' in Plan 9 source.
>
> To recap, the API works as follows:
>
> - shm_open(path) to open or create an shm object, get a file descriptor
> - shm_unlink(path) to remove the shm object from the path namespace
> - ftruncate(fd) to actually allocate n bytes for the shm object
> - fstat(fd) returns the size of the object in the st_size field
> - mmap(fd) to get a pointer to use the shared memory
>
> The shm fd works like other Unix fds (can be sent to an unrelated
> process over a Unix-domain socket, persists over fork(), and can persist
> over exec() if the close-on-exec flag is cleared). The kernel garbage
> collects the shm object after the last fd pointing to it is closed.
>
> I made the shim <https://github.com/lassik/shm_open_anon> to provide a
> "shm_open() without a pathname" on various Unix flavors. I'm wondering
> if Plan 9 support could be easily added.
>
> I should mention that I have never used Plan 9, just read some of the
> source and documentation.
>
> Regards,
> Lassi
>
>

[-- Attachment #2: Type: text/html, Size: 1807 bytes --]