shm_open.html

posix标准英文,html格式

<p>The following code segment demonstrates the use of <i>shm_open</i>() to create a shared memory object which is then sized using
<a href="../functions/ftruncate.html"><i>ftruncate</i>()</a> before being mapped into the process address space using <a href=
"../functions/mmap.html"><i>mmap</i>()</a>:</p>

<pre>
<tt>#include &lt;unistd.h&gt;
#include &lt;sys/mman.h&gt;
...
<br>
#define MAX_LEN 10000
struct region {        /* Defines "structure" of shared memory */
    int len;
    char buf[MAX_LEN];
};
struct region *rptr;
int fd;
<br>
/* Create shared memory object and set its size */
<br>
fd = shm_open("/myregion", O_CREAT | O_RDWR, S_IRUSR | S_IWUSR);
if (fd == -1)
    /* Handle error */;
<br>
if (ftruncate(fd, sizeof(struct region)) == -1)
    /* Handle error */;
<br>
/* Map shared memory object */
<br>
rptr = mmap(NULL, sizeof(struct region),
       PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
if (rptr == MAP_FAILED)
    /* Handle error */;
<br>
/* Now we can refer to mapped region using fields of rptr;
   for example, rptr-&gt;len */
...
</tt>
</pre>
</blockquote>

<h4><a name="tag_03_673_07"></a>APPLICATION USAGE</h4>

<blockquote>
<p>None.</p>
</blockquote>

<h4><a name="tag_03_673_08"></a>RATIONALE</h4>

<blockquote>
<p>When the Memory Mapped Files option is supported, the normal <a href="../functions/open.html"><i>open</i>()</a> call is used to
obtain a descriptor to a file to be mapped according to existing practice with <a href="../functions/mmap.html"><i>mmap</i>()</a>.
When the Shared Memory Objects option is supported, the <i>shm_open</i>() function shall obtain a descriptor to the shared memory
object to be mapped.</p>

<p>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 <a href="../functions/open.html"><i>open</i>()</a> or <a href=
"../functions/creat.html"><i>creat</i>()</a> and in some cases returned by alternate functions, such as <a href=
"../functions/pipe.html"><i>pipe</i>()</a>. The latter technique is used by <i>shm_open</i>().</p>

<p>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 <a href="../functions/ftruncate.html"><i>ftruncate</i>()</a>. The <i>shm_open</i>() 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.</p>

<p>On implementations where memory objects are implemented using the existing file system, the <i>shm_open</i>() function may be
implemented using a macro that invokes <a href="../functions/open.html"><i>open</i>()</a>, and the <a href=
"../functions/shm_unlink.html"><i>shm_unlink</i>()</a> function may be implemented using a macro that invokes <a href=
"../functions/unlink.html"><i>unlink</i>()</a>.</p>

<p>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.</p>

<p>On implementations that choose to implement memory objects using memory directly, a <i>shm_open</i>() followed by an <a href=
"../functions/ftruncate.html"><i>ftruncate</i>()</a> and <a href="../functions/close.html"><i>close</i>()</a> 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.</p>

<p>The set of valid open flags to <i>shm_open</i>() 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&nbsp;Std&nbsp;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.</p>

<p>The error conditions [EACCES] and [ENOTSUP] are provided to inform the application that the implementation cannot complete a
request.</p>

<p>[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.</p>

<p>[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.</p>

<p>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 <i>shm_open</i>() 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 <a href="../functions/getenv.html"><i>getenv</i>()</a>. Another would be from a configuration file.</p>

<p>This volume of IEEE&nbsp;Std&nbsp;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.</p>
</blockquote>

<h4><a name="tag_03_673_09"></a>FUTURE DIRECTIONS</h4>

<blockquote>
<p>None.</p>
</blockquote>

<h4><a name="tag_03_673_10"></a>SEE ALSO</h4>

<blockquote>
<p><a href="close.html"><i>close</i>()</a>, <a href="dup.html"><i>dup</i>()</a>, <a href="exec.html"><i><a href=
"../functions/exec.html">exec</a></i>()</a>, <a href="fcntl.html"><i>fcntl</i>()</a>, <a href="mmap.html"><i>mmap</i>()</a>, <a
href="shmat.html"><i>shmat</i>()</a>, <a href="shmctl.html"><i>shmctl</i>()</a>, <a href="shmdt.html"><i>shmdt</i>()</a>, <a
href="shm_unlink.html"><i>shm_unlink</i>()</a>, <a href="umask.html"><i>umask</i>()</a>, the Base Definitions volume of
IEEE&nbsp;Std&nbsp;1003.1-2001, <a href="../basedefs/fcntl.h.html"><i>&lt;fcntl.h&gt;</i></a>, <a href=
"../basedefs/sys/mman.h.html"><i>&lt;sys/mman.h&gt;</i></a></p>
</blockquote>

<h4><a name="tag_03_673_11"></a>CHANGE HISTORY</h4>

<blockquote>
<p>First released in Issue 5. Included for alignment with the POSIX Realtime Extension.</p>
</blockquote>

<h4><a name="tag_03_673_12"></a>Issue 6</h4>

<blockquote>
<p>The <i>shm_open</i>() function is marked as part of the Shared Memory Objects option.</p>

<p>The [ENOSYS] error condition has been removed as stubs need not be provided if an implementation does not support the Shared
Memory Objects option.</p>

<p>IEEE&nbsp;Std&nbsp;1003.1-2001/Cor&nbsp;2-2004, item XSH/TC2/D6/126 is applied, adding the example to the EXAMPLES section.</p>
</blockquote>

<div class="box"><em>End of informative text.</em></div>

<hr size="2" noshade>
<center><font size="2"><!--footer start-->
UNIX &reg; is a registered Trademark of The Open Group.<br>
POSIX &reg; is a registered Trademark of The IEEE.<br>
[ <a href="../mindex.html">Main Index</a> | <a href="../basedefs/contents.html">XBD</a> | <a href=
"../utilities/contents.html">XCU</a> | <a href="../functions/contents.html">XSH</a> | <a href="../xrat/contents.html">XRAT</a>
]</font></center>

<!--footer end-->
<hr size="2" noshade>
</body>
</html>