1SHM_OPEN(P)                POSIX Programmer's Manual               SHM_OPEN(P)
2
3
4

NAME

6       shm_open - open a shared memory object (REALTIME)
7

SYNOPSIS

9       #include <sys/mman.h>
10
11       int shm_open(const char *name, int oflag, mode_t mode);
12
13

DESCRIPTION

15       The  shm_open()  function shall establish a connection between a shared
16       memory object and a file descriptor.  It  shall  create  an  open  file
17       description that refers to the shared memory object and a file descrip‐
18       tor that refers to that open file description. The file  descriptor  is
19       used by other functions to refer to that shared memory object. The name
20       argument points to a string  naming  a  shared  memory  object.  It  is
21       unspecified  whether the name appears in the file system and is visible
22       to other functions that take pathnames as arguments. The name  argument
23       conforms  to the construction rules for a pathname. If name begins with
24       the slash character, then processes calling shm_open()  with  the  same
25       value  of  name refer to the same shared memory object, as long as that
26       name has not been removed.  If name does not begin with the slash char‐
27       acter,  the  effect  is  implementation-defined.  The interpretation of
28       slash characters other than the leading  slash  character  in  name  is
29       implementation-defined.
30
31       If successful, shm_open() shall return a file descriptor for the shared
32       memory object that is the lowest numbered file descriptor not currently
33       open  for that process. The open file description is new, and therefore
34       the file descriptor does not share it with any other processes.  It  is
35       unspecified  whether  the  file  offset  is  set.  The  FD_CLOEXEC file
36       descriptor flag associated with the new file descriptor is set.
37
38       The file status flags and file access modes of the open  file  descrip‐
39       tion  are  according  to  the value of oflag. The oflag argument is the
40       bitwise-inclusive OR of the following flags defined  in  the  <fcntl.h>
41       header.  Applications  specify  exactly  one  of  the  first two values
42       (access modes) below in the value of oflag:
43
44       O_RDONLY
45              Open for read access only.
46
47       O_RDWR Open for read or write access.
48
49
50       Any combination of the remaining flags may be specified in the value of
51       oflag:
52
53       O_CREAT
54              If  the  shared  memory  object exists, this flag has no effect,
55              except as noted under O_EXCL below. Otherwise, the shared memory
56              object is created; the user ID of the shared memory object shall
57              be set to the effective user ID of the process; the group ID  of
58              the  shared memory object is set to a system default group ID or
59              to the effective group ID of the process. The permission bits of
60              the  shared  memory object shall be set to the value of the mode
61              argument except those set in the file mode creation mask of  the
62              process.  When  bits in mode other than the file permission bits
63              are set, the effect is unspecified. The mode argument  does  not
64              affect  whether  the shared memory object is opened for reading,
65              for writing, or for both. The shared memory object has a size of
66              zero.
67
68       O_EXCL If  O_EXCL  and  O_CREAT are set, shm_open() fails if the shared
69              memory object exists. The check for the existence of the  shared
70              memory  object  and  the  creation  of the object if it does not
71              exist is  atomic  with  respect  to  other  processes  executing
72              shm_open()  naming the same shared memory object with O_EXCL and
73              O_CREAT set. If O_EXCL is set and O_CREAT is not set, the result
74              is undefined.
75
76       O_TRUNC
77              If  the  shared  memory  object  exists,  and it is successfully
78              opened O_RDWR, the object shall be truncated to zero length  and
79              the mode and owner shall be unchanged by this function call. The
80              result of using O_TRUNC with O_RDONLY is undefined.
81
82
83       When a shared memory object is created, the state of the shared  memory
84       object,  including  all  data associated with the shared memory object,
85       persists until the shared memory object is unlinked and all other  ref‐
86       erences  are gone. It is unspecified whether the name and shared memory
87       object state remain valid after a system reboot.
88

RETURN VALUE

90       Upon successful completion, the shm_open() function shall return a non-
91       negative  integer representing the lowest numbered unused file descrip‐
92       tor. Otherwise, it shall return -1 and set errno to indicate the error.
93

ERRORS

95       The shm_open() function shall fail if:
96
97       EACCES The shared memory object exists and the permissions specified by
98              oflag are denied, or the shared memory object does not exist and
99              permission to create the shared  memory  object  is  denied,  or
100              O_TRUNC is specified and write permission is denied.
101
102       EEXIST O_CREAT  and  O_EXCL  are set and the named shared memory object
103              already exists.
104
105       EINTR  The shm_open() operation was interrupted by a signal.
106
107       EINVAL The shm_open() operation is not supported for the given name.
108
109       EMFILE Too many file descriptors are currently in use by this process.
110
111       ENAMETOOLONG
112              The length of the name argument exceeds {PATH_MAX} or a pathname
113              component is longer than {NAME_MAX}.
114
115       ENFILE Too many shared memory objects are currently open in the system.
116
117       ENOENT O_CREAT  is  not set and the named shared memory object does not
118              exist.
119
120       ENOSPC There is insufficient space for the creation of the  new  shared
121              memory object.
122
123
124       The following sections are informative.
125

EXAMPLES

127       None.
128

APPLICATION USAGE

130       None.
131

RATIONALE

133       When  the  Memory  Mapped  Files option is supported, the normal open()
134       call is used to obtain a descriptor to a file to be mapped according to
135       existing  practice  with mmap().  When the Shared Memory Objects option
136       is supported, the shm_open() function shall obtain a descriptor to  the
137       shared memory object to be mapped.
138
139       There is ample precedent for having a file descriptor represent several
140       types of objects. In the POSIX.1-1990 standard, a file  descriptor  can
141       represent  a  file, a pipe, a FIFO, a tty, or a directory.  Many imple‐
142       mentations simply have an operations vector, which is  indexed  by  the
143       file  descriptor  type and does very different operations. Note that in
144       some cases the file descriptor passed to  generic  operations  on  file
145       descriptors is returned by open() or creat() and in some cases returned
146       by alternate functions, such as pipe(). The latter technique is used by
147       shm_open().
148
149       Note  that  such  shared  memory objects can actually be implemented as
150       mapped files. In both cases, the size can be set after the  open  using
151       ftruncate().  The  shm_open()  function itself does not create a shared
152       object of a specified size because this would duplicate an extant func‐
153       tion that set the size of an object referenced by a file descriptor.
154
155       On  implementations  where  memory  objects  are  implemented using the
156       existing file system, the shm_open() function may be implemented  using
157       a  macro  that  invokes  open(),  and  the shm_unlink() function may be
158       implemented using a macro that invokes unlink().
159
160       For implementations without a permanent file system, the definition  of
161       the  name  of  the  memory  objects  is allowed not to survive a system
162       reboot. Note that this allows systems with a permanent file  system  to
163       implement memory objects as data structures internal to the implementa‐
164       tion as well.
165
166       On implementations that choose to implement memory objects using memory
167       directly,  a  shm_open()  followed by an ftruncate() and close() can be
168       used to preallocate a shared memory area and to set the  size  of  that
169       preallocation.   This may be necessary for systems without virtual mem‐
170       ory hardware support in order to ensure that the memory is contiguous.
171
172       The set of valid open flags to shm_open() was restricted  to  O_RDONLY,
173       O_RDWR,  O_CREAT, and O_TRUNC because these could be easily implemented
174       on most memory mapping systems. This volume of IEEE Std 1003.1-2001  is
175       silent on the results if the implementation cannot supply the requested
176       file access because of implementation-defined reasons, including  hard‐
177       ware ones.
178
179       The  error conditions [EACCES] and [ENOTSUP] are provided to inform the
180       application that the implementation cannot complete a request.
181
182       [EACCES] indicates for implementation-defined reasons,  probably  hard‐
183       ware-related,  that  the  implementation cannot comply with a requested
184       mode because it conflicts with another requested mode. An example might
185       be  that an application desires to open a memory object two times, map‐
186       ping different areas with different access modes.  If  the  implementa‐
187       tion cannot map a single area into a process space in two places, which
188       would be required if different access modes were required for  the  two
189       areas,  then  the implementation may inform the application at the time
190       of the second open.
191
192       [ENOTSUP] indicates for implementation-defined reasons, probably  hard‐
193       ware-related,  that  the  implementation cannot comply with a requested
194       mode at all. An example would be that the hardware of  the  implementa‐
195       tion cannot support write-only shared memory areas.
196
197       On all implementations, it may be desirable to restrict the location of
198       the memory objects to specific file systems for performance (such as  a
199       RAM  disk)  or  implementation-defined reasons (shared memory supported
200       directly only on certain file systems).  The shm_open() function may be
201       used  to  enforce  these  restrictions.   There are a number of methods
202       available to the application to determine an appropriate  name  of  the
203       file  or  the location of an appropriate directory. One way is from the
204       environment via getenv(). Another would be from a configuration file.
205
206       This volume of IEEE Std 1003.1-2001 specifies that memory objects  have
207       initial  contents of zero when created. This is consistent with current
208       behavior for both files and newly allocated memory. For those implemen‐
209       tations that use physical memory, it would be possible that such imple‐
210       mentations could simply use available memory and give it to the process
211       uninitialized.  This, however, is not consistent with standard behavior
212       for the uninitialized data area,  the  stack,  and  of  course,  files.
213       Finally, it is highly desirable to set the allocated memory to zero for
214       security  reasons.  Thus,  initializing  memory  objects  to  zero   is
215       required.
216

FUTURE DIRECTIONS

218       None.
219

SEE ALSO

221       close()  ,  dup()  ,  exec()  , fcntl() , mmap() , shmat() , shmctl() ,
222       shmdt() , shm_unlink() , umask()  ,  the  Base  Definitions  volume  of
223       IEEE Std 1003.1-2001, <fcntl.h>, <sys/mman.h>
224
226       Portions  of  this text are reprinted and reproduced in electronic form
227       from IEEE Std 1003.1, 2003 Edition, Standard for Information Technology
228       --  Portable  Operating  System  Interface (POSIX), The Open Group Base
229       Specifications Issue 6, Copyright (C) 2001-2003  by  the  Institute  of
230       Electrical  and  Electronics  Engineers, Inc and The Open Group. In the
231       event of any discrepancy between this version and the original IEEE and
232       The  Open Group Standard, the original IEEE and The Open Group Standard
233       is the referee document. The original Standard can be  obtained  online
234       at http://www.opengroup.org/unix/online.html .
235
236
237
238IEEE/The Open Group                  2003                          SHM_OPEN(P)
Impressum