On Wed, 24 Apr 2019 18:22:35 +0300, Lassi Kortela <la...@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
