Originální popis anglicky:
shm_open - open a shared memory object (
REALTIME)
Návod, kniha: POSIX Programmer's Manual
#include <sys/mman.h>
int shm_open(const char *
name, int
oflag , mode_t mode);
The
shm_open() function shall establish a connection between a shared
memory object and a file descriptor. It shall create an open file description
that refers to the shared memory object and a file descriptor that refers to
that open file description. The file descriptor is used by other functions to
refer to that shared memory object. The
name argument points to a
string naming a shared memory object. It is unspecified whether the name
appears in the file system and is visible to other functions that take
pathnames as arguments. The
name argument conforms to the construction
rules for a pathname. If
name begins with the slash character, then
processes calling
shm_open() with the same value of
name refer
to the same shared memory object, as long as that name has not been removed.
If
name does not begin with the slash character, the effect is
implementation-defined. The interpretation of slash characters other than the
leading slash character in
name is implementation-defined.
If successful,
shm_open() shall return a file descriptor for the shared
memory object that is the lowest numbered file descriptor not currently open
for that process. The open file description is new, and therefore the file
descriptor does not share it with any other processes. It is unspecified
whether the file offset is set. The FD_CLOEXEC file descriptor flag associated
with the new file descriptor is set.
The file status flags and file access modes of the open file description are
according to the value of
oflag. The
oflag argument is the
bitwise-inclusive OR of the following flags defined in the
<fcntl.h> header. Applications specify exactly one of the first
two values (access modes) below in the value of
oflag:
- O_RDONLY
- Open for read access only.
- O_RDWR
- Open for read or write access.
Any combination of the remaining flags may be specified in the value of
oflag:
- O_CREAT
- If the shared memory object exists, this flag has no
effect, except as noted under O_EXCL below. Otherwise, the shared memory
object is created; the user ID of the shared memory object shall be set to
the effective user ID of the process; the group ID of the shared memory
object is set to a system default group ID or to the effective group ID of
the process. The permission bits of the shared memory object shall be set
to the value of the mode argument except those set in the file mode
creation mask of the process. When bits in mode other than the file
permission bits are set, the effect is unspecified. The mode
argument does not affect whether the shared memory object is opened for
reading, for writing, or for both. The shared memory object has a size of
zero.
- O_EXCL
- If O_EXCL and O_CREAT are set, shm_open() fails if
the shared memory object exists. The check for the existence of the shared
memory object and the creation of the object if it does not exist is
atomic with respect to other processes executing shm_open() naming
the same shared memory object with O_EXCL and O_CREAT set. If O_EXCL is
set and O_CREAT is not set, the result is undefined.
- O_TRUNC
- If the shared memory object exists, and it is successfully
opened O_RDWR, the object shall be truncated to zero length and the mode
and owner shall be unchanged by this function call. The result of using
O_TRUNC with O_RDONLY is undefined.
When a shared memory object is created, the state of the shared memory object,
including all data associated with the shared memory object, persists until
the shared memory object is unlinked and all other references are gone. It is
unspecified whether the name and shared memory object state remain valid after
a system reboot.
Upon successful completion, the
shm_open() function shall return a
non-negative integer representing the lowest numbered unused file descriptor.
Otherwise, it shall return -1 and set
errno to indicate the error.
The
shm_open() function shall fail if:
- EACCES
- The shared memory object exists and the permissions
specified by oflag are denied, or the shared memory object does not
exist and permission to create the shared memory object is denied, or
O_TRUNC is specified and write permission is denied.
- EEXIST
- O_CREAT and O_EXCL are set and the named shared memory
object already exists.
- EINTR
- The shm_open() operation was interrupted by a
signal.
- EINVAL
- The shm_open() operation is not supported for the
given name.
- EMFILE
- Too many file descriptors are currently in use by this
process.
- ENAMETOOLONG
- The length of the name argument exceeds {PATH_MAX}
or a pathname component is longer than {NAME_MAX}.
- ENFILE
- Too many shared memory objects are currently open in the
system.
- ENOENT
- O_CREAT is not set and the named shared memory object does
not exist.
- ENOSPC
- There is insufficient space for the creation of the new
shared memory object.
The following sections are informative.
None.
None.
When the Memory Mapped Files option is supported, the normal
open() call
is used to obtain a descriptor to a file to be mapped according to existing
practice with
mmap(). When the Shared Memory Objects option is
supported, the
shm_open() function shall obtain a descriptor to the
shared memory object to be mapped.
There is ample precedent for having a file descriptor represent several types of
objects. In the POSIX.1-1990 standard, a file descriptor can represent a file,
a pipe, a FIFO, a tty, or a directory. Many implementations simply have an
operations vector, which is indexed by the file descriptor type and does very
different operations. Note that in some cases the file descriptor passed to
generic operations on file descriptors is returned by
open() or
creat() and in some cases returned by alternate functions, such as
pipe(). The latter technique is used by
shm_open().
Note that such shared memory objects can actually be implemented as mapped
files. In both cases, the size can be set after the open using
ftruncate(). The
shm_open() function itself does not create a
shared object of a specified size because this would duplicate an extant
function that set the size of an object referenced by a file descriptor.
On implementations where memory objects are implemented using the existing file
system, the
shm_open() function may be implemented using a macro that
invokes
open(), and the
shm_unlink() function may be implemented
using a macro that invokes
unlink().
For implementations without a permanent file system, the definition of the name
of the memory objects is allowed not to survive a system reboot. Note that
this allows systems with a permanent file system to implement memory objects
as data structures internal to the implementation as well.
On implementations that choose to implement memory objects using memory
directly, a
shm_open() followed by an
ftruncate() and
close() can be used to preallocate a shared memory area and to set the
size of that preallocation. This may be necessary for systems without virtual
memory hardware support in order to ensure that the memory is contiguous.
The set of valid open flags to
shm_open() was restricted to O_RDONLY,
O_RDWR, O_CREAT, and O_TRUNC because these could be easily implemented on most
memory mapping systems. This volume of IEEE Std 1003.1-2001 is
silent on the results if the implementation cannot supply the requested file
access because of implementation-defined reasons, including hardware ones.
The error conditions [EACCES] and [ENOTSUP] are provided to inform the
application that the implementation cannot complete a request.
[EACCES] indicates for implementation-defined reasons, probably
hardware-related, that the implementation cannot comply with a requested mode
because it conflicts with another requested mode. An example might be that an
application desires to open a memory object two times, mapping different areas
with different access modes. If the implementation cannot map a single area
into a process space in two places, which would be required if different
access modes were required for the two areas, then the implementation may
inform the application at the time of the second open.
[ENOTSUP] indicates for implementation-defined reasons, probably
hardware-related, that the implementation cannot comply with a requested mode
at all. An example would be that the hardware of the implementation cannot
support write-only shared memory areas.
On all implementations, it may be desirable to restrict the location of the
memory objects to specific file systems for performance (such as a RAM disk)
or implementation-defined reasons (shared memory supported directly only on
certain file systems). The
shm_open() function may be used to enforce
these restrictions. There are a number of methods available to the application
to determine an appropriate name of the file or the location of an appropriate
directory. One way is from the environment via
getenv(). Another would
be from a configuration file.
This volume of IEEE Std 1003.1-2001 specifies that memory objects
have initial contents of zero when created. This is consistent with current
behavior for both files and newly allocated memory. For those implementations
that use physical memory, it would be possible that such implementations could
simply use available memory and give it to the process uninitialized. This,
however, is not consistent with standard behavior for the uninitialized data
area, the stack, and of course, files. Finally, it is highly desirable to set
the allocated memory to zero for security reasons. Thus, initializing memory
objects to zero is required.
None.
close() ,
dup() ,
exec() ,
fcntl() ,
mmap() ,
shmat() ,
shmctl() ,
shmdt() ,
shm_unlink() ,
umask() , the Base Definitions volume of
IEEE Std 1003.1-2001,
<fcntl.h>,
<sys/mman.h>
Portions of this text are reprinted and reproduced in electronic form from IEEE
Std 1003.1, 2003 Edition, Standard for Information Technology -- Portable
Operating System Interface (POSIX), The Open Group Base Specifications Issue
6, Copyright (C) 2001-2003 by the Institute of Electrical and Electronics
Engineers, Inc and The Open Group. In the event of any discrepancy between
this version and the original IEEE and The Open Group Standard, the original
IEEE and The Open Group Standard is the referee document. The original
Standard can be obtained online at http://www.opengroup.org/unix/online.html
.
