shmget vs. shm_open

[bill pursell]

Can anyone point me to a comparison of using sysVr4 shmget() calls
versus Posix shm_open()? Is there a reason (other than wanting to
conform to one standard vs. the other) to choose one over the other?
If my app is only going to be running on Linux, does it matter which
style of shared memory I choose to use?

[Larry I Smith]

Post by bill pursell
Can anyone point me to a comparison of using sysVr4 shmget() calls
versus Posix shm_open()? Is there a reason (other than wanting to
conform to one standard vs. the other) to choose one over the other?
If my app is only going to be running on Linux, does it matter which
style of shared memory I choose to use?

shm_open() allows multiple un-related processes to access
the same shared memory - since it can be accessed by a well
know name.

shmget() requires some way for the creating process to
give the 'key' used to create the memory to other processes
so they can access it. sometimes the creating process
writes the 'key' to a well known file name so that other
un-related processes can read the key.

if the creating process only needs to share the memory with
child processes created via fork(), then shmget() is ok;
otherwise, shm_open() is often used.

Larry

[Nils O. Selåsdal]

Post by Larry I Smith

Post by bill pursell
Can anyone point me to a comparison of using sysVr4 shmget() calls
versus Posix shm_open()? Is there a reason (other than wanting to
conform to one standard vs. the other) to choose one over the other?
If my app is only going to be running on Linux, does it matter which
style of shared memory I choose to use?

shm_open() allows multiple un-related processes to access
the same shared memory - since it can be accessed by a well
know name.
shmget() requires some way for the creating process to
give the 'key' used to create the memory to other processes
so they can access it. sometimes the creating process
writes the 'key' to a well known file name so that other
un-related processes can read the key.
if the creating process only needs to share the memory with
child processes created via fork(), then shmget() is ok;
otherwise, shm_open() is often used.

Well, unrelated process can just call ftok to get the same key.

shmget is an old function emerging from the At&T unix, and later
specified in the single unix specification.
shm_open is more or less a newer version og shmget specified by posix -
and isn't yet as widely implemented as shmget

[Larry I Smith]

Post by Nils O. Selåsdal

Post by Larry I Smith

Post by bill pursell
Can anyone point me to a comparison of using sysVr4 shmget() calls
versus Posix shm_open()? Is there a reason (other than wanting to
conform to one standard vs. the other) to choose one over the other?
If my app is only going to be running on Linux, does it matter which
style of shared memory I choose to use?

shm_open() allows multiple un-related processes to access
the same shared memory - since it can be accessed by a well
know name.
shmget() requires some way for the creating process to
give the 'key' used to create the memory to other processes
so they can access it. sometimes the creating process
writes the 'key' to a well known file name so that other
un-related processes can read the key.
if the creating process only needs to share the memory with
child processes created via fork(), then shmget() is ok;
otherwise, shm_open() is often used.

Well, unrelated process can just call ftok to get the same key.

Assuming they know what the key is. That usually means they
obtained it via some shared file, some IPC mechanism, or it
was compiled in. Then you might as well use shm_open() and be
POSIX compliant.

Post by Nils O. Selåsdal
shmget is an old function emerging from the At&T unix, and later
specified in the single unix specification.
shm_open is more or less a newer version og shmget specified by posix -
and isn't yet as widely implemented as shmget

Larry

[Nils O. Selåsdal]

Post by Larry I Smith

Post by Nils O. Selåsdal

Post by Larry I Smith

Post by bill pursell
Can anyone point me to a comparison of using sysVr4 shmget() calls
versus Posix shm_open()? Is there a reason (other than wanting to
conform to one standard vs. the other) to choose one over the other?
If my app is only going to be running on Linux, does it matter which
style of shared memory I choose to use?

shm_open() allows multiple un-related processes to access
the same shared memory - since it can be accessed by a well
know name.
shmget() requires some way for the creating process to
give the 'key' used to create the memory to other processes
so they can access it. sometimes the creating process
writes the 'key' to a well known file name so that other
un-related processes can read the key.
if the creating process only needs to share the memory with
child processes created via fork(), then shmget() is ok;
otherwise, shm_open() is often used.

Well, unrelated process can just call ftok to get the same key.

Assuming they know what the key is. That usually means they
obtained it via some shared file, some IPC mechanism, or it

You need that with shm_open as well.
ftok("/tmp/foo",0); vs
and shm_open("/tmp/foo,....); ?

Post by Larry I Smith
was compiled in. Then you might as well use shm_open() and be
POSIX compliant.

Indeed.

But as mentioned shm_open isn't as widely implemented yet.

[Kasper Dupont]

Post by Nils O. Selåsdal
and shm_open("/tmp/foo,....); ?

On my system shm_open(3) advice against such a name:

For portable use, name should have an initial
slash (/) and contain no embedded slashes.

[Larry I Smith]

Post by Kasper Dupont

Post by Nils O. Selåsdal
and shm_open("/tmp/foo,....); ?

For portable use, name should have an initial
slash (/) and contain no embedded slashes.

You are correct.

Shared memory files must start with '/', and must not
contain any embedded '/' chars to be portable.

linux puts them in /dev/shm. So a shared memory
named "/myApp" ends up in /dev/shm/myApp.

This scheme allows un-related apps to find the size
of the shared memory.

Regards,
Larry

[Roger Leigh]

Post by Nils O. Selåsdal

Post by Larry I Smith
was compiled in. Then you might as well use shm_open() and be
POSIX compliant.

Indeed.
But as mentioned shm_open isn't as widely implemented yet.

Since it's been available since linux 2.4, every contemporary linux
system will implement it. Just my opinion, but I personally regard
that as being supported well enough now to use in general-purpose
linux code.


Regards,
Roger

[Nils O. Selåsdal]

Post by Roger Leigh

Post by Nils O. Selåsdal

Post by Larry I Smith
was compiled in. Then you might as well use shm_open() and be
POSIX compliant.

Indeed.
But as mentioned shm_open isn't as widely implemented yet.

Since it's been available since linux 2.4, every contemporary linux
system will implement it. Just my opinion, but I personally regard
that as being supported well enough now to use in general-purpose
linux code.

Fair enough, if you only target linux, use shm_open.

[Ilja Tabachnik]

Post by Nils O. Selåsdal
Fair enough, if you only target linux, use shm_open.

Hmmm... what's wrong with Solaris? AFAIK Solaris had
POSIX shared memory support already in Solaris 2.6 (!).
Also AIX (at least AIX 5) does support shm_open.

[Ian Clarke]

Post by Ilja Tabachnik

Post by Nils O. Selåsdal
Fair enough, if you only target linux, use shm_open.

Hmmm... what's wrong with Solaris? AFAIK Solaris had
POSIX shared memory support already in Solaris 2.6 (!).
Also AIX (at least AIX 5) does support shm_open.

Just about every modern Unix has shmget(), but some BSDs
(OpenBSD and NetBSD IIRC) do not have shm_open().

[Kasper Dupont]

Post by bill pursell
Can anyone point me to a comparison of using sysVr4 shmget() calls
versus Posix shm_open()? Is there a reason (other than wanting to
conform to one standard vs. the other) to choose one over the other?
If my app is only going to be running on Linux, does it matter which
style of shared memory I choose to use?

I think Posix shared memory is more convenient. The API
is essentially the same as with memory mapped files, and
the semantics are also the same. Posix shared memory
also allows you to easilly map a part of a shared memory
segment, something which SysV shared memory does not.
And AFAIK only Posix shared memory have a clear semantics
in case you delete a shared memory segment while it is
still mapped. This is something one needs to do in order
to avoid leaks in case of unexpected termination.