1SHM_OPEN(3P) POSIX Programmer's Manual SHM_OPEN(3P)
2
6 This manual page is part of the POSIX Programmer's Manual. The Linux
7 implementation of this interface may differ (consult the corresponding
8 Linux manual page for details of Linux behavior), or the interface may
9 not be implemented on Linux.
10
12 shm_open - open a shared memory object (REALTIME)
13
15 #include <sys/mman.h>
16 int shm_open(const char *name, int oflag, mode_t mode);
18
21 The shm_open() function shall establish a connection between a shared
22 memory object and a file descriptor. It shall create an open file
23 description that refers to the shared memory object and a file descrip‐
24 tor that refers to that open file description. The file descriptor is
25 used by other functions to refer to that shared memory object. The name
26 argument points to a string naming a shared memory object. It is
27 unspecified whether the name appears in the file system and is visible
28 to other functions that take pathnames as arguments. The name argument
29 conforms to the construction rules for a pathname. If name begins with
30 the slash character, then processes calling shm_open() with the same
31 value of name refer to the same shared memory object, as long as that
32 name has not been removed. If name does not begin with the slash char‐
33 acter, the effect is implementation-defined. The interpretation of
34 slash characters other than the leading slash character in name is
35 implementation-defined.
36 If successful, shm_open() shall return a file descriptor for the shared
38 memory object that is the lowest numbered file descriptor not currently
39 open for that process. The open file description is new, and therefore
40 the file descriptor does not share it with any other processes. It is
41 unspecified whether the file offset is set. The FD_CLOEXEC file
42 descriptor flag associated with the new file descriptor is set.
43 The file status flags and file access modes of the open file descrip‐
45 tion are according to the value of oflag. The oflag argument is the
46 bitwise-inclusive OR of the following flags defined in the <fcntl.h>
47 header. Applications specify exactly one of the first two values
48 (access modes) below in the value of oflag:
49 O_RDONLY
51 Open for read access only.
52 O_RDWR Open for read or write access.
54 Any combination of the remaining flags may be specified in the value of
57 oflag:
58 O_CREAT
60 If the shared memory object exists, this flag has no effect,
61 except as noted under O_EXCL below. Otherwise, the shared memory
62 object is created; the user ID of the shared memory object shall
63 be set to the effective user ID of the process; the group ID of
64 the shared memory object is set to a system default group ID or
65 to the effective group ID of the process. The permission bits of
66 the shared memory object shall be set to the value of the mode
67 argument except those set in the file mode creation mask of the
68 process. When bits in mode other than the file permission bits
69 are set, the effect is unspecified. The mode argument does not
70 affect whether the shared memory object is opened for reading,
71 for writing, or for both. The shared memory object has a size of
72 zero.
73 O_EXCL If O_EXCL and O_CREAT are set, shm_open() fails if the shared
75 memory object exists. The check for the existence of the shared
76 memory object and the creation of the object if it does not
77 exist is atomic with respect to other processes executing
78 shm_open() naming the same shared memory object with O_EXCL and
79 O_CREAT set. If O_EXCL is set and O_CREAT is not set, the result
80 is undefined.
81 O_TRUNC
83 If the shared memory object exists, and it is successfully
84 opened O_RDWR, the object shall be truncated to zero length and
85 the mode and owner shall be unchanged by this function call. The
86 result of using O_TRUNC with O_RDONLY is undefined.
87 When a shared memory object is created, the state of the shared memory
90 object, including all data associated with the shared memory object,
91 persists until the shared memory object is unlinked and all other ref‐
92 erences are gone. It is unspecified whether the name and shared memory
93 object state remain valid after a system reboot.
94
96 Upon successful completion, the shm_open() function shall return a non-
97 negative integer representing the lowest numbered unused file descrip‐
98 tor. Otherwise, it shall return -1 and set errno to indicate the error.
99
101 The shm_open() function shall fail if:
102 EACCES The shared memory object exists and the permissions specified by
104 oflag are denied, or the shared memory object does not exist and
105 permission to create the shared memory object is denied, or
106 O_TRUNC is specified and write permission is denied.
107 EEXIST O_CREAT and O_EXCL are set and the named shared memory object
109 already exists.
110 EINTR The shm_open() operation was interrupted by a signal.
112 EINVAL The shm_open() operation is not supported for the given name.
114 EMFILE Too many file descriptors are currently in use by this process.
116 ENAMETOOLONG
118 The length of the name argument exceeds {PATH_MAX} or a pathname
119 component is longer than {NAME_MAX}.
120 ENFILE Too many shared memory objects are currently open in the system.
122 ENOENT O_CREAT is not set and the named shared memory object does not
124 exist.
125 ENOSPC There is insufficient space for the creation of the new shared
127 memory object.
128 The following sections are informative.
131
133 None.
134
136 None.
137
139 When the Memory Mapped Files option is supported, the normal open()
140 call is used to obtain a descriptor to a file to be mapped according to
141 existing practice with mmap(). When the Shared Memory Objects option
142 is supported, the shm_open() function shall obtain a descriptor to the
143 shared memory object to be mapped.
144 There is ample precedent for having a file descriptor represent several
146 types of objects. In the POSIX.1-1990 standard, a file descriptor can
147 represent a file, a pipe, a FIFO, a tty, or a directory. Many imple‐
148 mentations simply have an operations vector, which is indexed by the
149 file descriptor type and does very different operations. Note that in
150 some cases the file descriptor passed to generic operations on file
151 descriptors is returned by open() or creat() and in some cases returned
152 by alternate functions, such as pipe(). The latter technique is used by
153 shm_open().
154 Note that such shared memory objects can actually be implemented as
156 mapped files. In both cases, the size can be set after the open using
157 ftruncate(). The shm_open() function itself does not create a shared
158 object of a specified size because this would duplicate an extant func‐
159 tion that set the size of an object referenced by a file descriptor.
160 On implementations where memory objects are implemented using the
162 existing file system, the shm_open() function may be implemented using
163 a macro that invokes open(), and the shm_unlink() function may be
164 implemented using a macro that invokes unlink().
165 For implementations without a permanent file system, the definition of
167 the name of the memory objects is allowed not to survive a system
168 reboot. Note that this allows systems with a permanent file system to
169 implement memory objects as data structures internal to the implementa‐
170 tion as well.
171 On implementations that choose to implement memory objects using memory
173 directly, a shm_open() followed by an ftruncate() and close() can be
174 used to preallocate a shared memory area and to set the size of that
175 preallocation. This may be necessary for systems without virtual mem‐
176 ory hardware support in order to ensure that the memory is contiguous.
177 The set of valid open flags to shm_open() was restricted to O_RDONLY,
179 O_RDWR, O_CREAT, and O_TRUNC because these could be easily implemented
180 on most memory mapping systems. This volume of IEEE Std 1003.1-2001 is
181 silent on the results if the implementation cannot supply the requested
182 file access because of implementation-defined reasons, including hard‐
183 ware ones.
184 The error conditions [EACCES] and [ENOTSUP] are provided to inform the
186 application that the implementation cannot complete a request.
187 [EACCES] indicates for implementation-defined reasons, probably hard‐
189 ware-related, that the implementation cannot comply with a requested
190 mode because it conflicts with another requested mode. An example might
191 be that an application desires to open a memory object two times, map‐
192 ping different areas with different access modes. If the implementa‐
193 tion cannot map a single area into a process space in two places, which
194 would be required if different access modes were required for the two
195 areas, then the implementation may inform the application at the time
196 of the second open.
197 [ENOTSUP] indicates for implementation-defined reasons, probably hard‐
199 ware-related, that the implementation cannot comply with a requested
200 mode at all. An example would be that the hardware of the implementa‐
201 tion cannot support write-only shared memory areas.
202 On all implementations, it may be desirable to restrict the location of
204 the memory objects to specific file systems for performance (such as a
205 RAM disk) or implementation-defined reasons (shared memory supported
206 directly only on certain file systems). The shm_open() function may be
207 used to enforce these restrictions. There are a number of methods
208 available to the application to determine an appropriate name of the
209 file or the location of an appropriate directory. One way is from the
210 environment via getenv(). Another would be from a configuration file.
211 This volume of IEEE Std 1003.1-2001 specifies that memory objects have
213 initial contents of zero when created. This is consistent with current
214 behavior for both files and newly allocated memory. For those implemen‐
215 tations that use physical memory, it would be possible that such imple‐
216 mentations could simply use available memory and give it to the process
217 uninitialized. This, however, is not consistent with standard behavior
218 for the uninitialized data area, the stack, and of course, files.
219 Finally, it is highly desirable to set the allocated memory to zero for
220 security reasons. Thus, initializing memory objects to zero is
221 required.
222
224 None.
225
227 close(), dup(), exec(), fcntl(), mmap(), shmat(), shmctl(), shmdt(),
228 shm_unlink(), umask(), the Base Definitions volume of
229 IEEE Std 1003.1-2001, <fcntl.h>, <sys/mman.h>
230
232 Portions of this text are reprinted and reproduced in electronic form
233 from IEEE Std 1003.1, 2003 Edition, Standard for Information Technology
234 -- Portable Operating System Interface (POSIX), The Open Group Base
235 Specifications Issue 6, Copyright (C) 2001-2003 by the Institute of
236 Electrical and Electronics Engineers, Inc and The Open Group. In the
237 event of any discrepancy between this version and the original IEEE and
238 The Open Group Standard, the original IEEE and The Open Group Standard
239 is the referee document. The original Standard can be obtained online
240 at http://www.opengroup.org/unix/online.html .
241IEEE/The Open Group 2003 SHM_OPEN(3P)