--- mm.pod 2005/09/02 20:00:46 1.24
+++ mm.pod 2006/06/10 07:07:54 1.25
@@ -151,7 +151,7 @@
type `C<MM *>' as its first argument. This API provides a comfortable way to
work with small dynamically allocated shared memory chunks inside large
statically allocated shared memory segments. It is internally based on the
-I<Low-Level Shared Memory API> for creating the underlaying shared memory
+I<Low-Level Shared Memory API> for creating the underlying shared memory
segment.
=item B<Low-Level Shared Memory API>
@@ -221,7 +221,7 @@
=item 4.2BSD-style flock(2) on temporary file (FLOCK)
I<Advantage:> exists on a lot of platforms, especially on older Unix
-derivates. I<Disadvantage:> needs a temporary file on the filesystem and has
+derivatives. I<Disadvantage:> needs a temporary file on the filesystem and has
to re-open file-descriptors to it in each(!) fork(2)'ed child process.
=item SysV IPC semget(2) (IPCSEM)
@@ -303,7 +303,7 @@
=item int B<MM_permission>(mode_t I<mode>, uid_t I<owner>, gid_t I<group>);
This sets the filesystem I<mode>, I<owner> and I<group> for the global shared
-memory pool (has effects only if the underlaying shared memory segment
+memory pool (has effects only if the underlying shared memory segment
implementation is actually based on external auxiliary files). The arguments
are directly passed through to chmod(2) and chown(2).
@@ -391,7 +391,7 @@
=item int B<mm_permission>(MM *I<mm>, mode_t I<mode>, uid_t I<owner>, gid_t I<group>);
This sets the filesystem I<mode>, I<owner> and I<group> for the shared memory
-pool I<mm> (has effects only when the underlaying shared memory segment
+pool I<mm> (has effects only when the underlying shared memory segment
implementation is actually based on external auxiliary files). The arguments
are directly passed through to chmod(2) and chown(2).
@@ -419,21 +419,21 @@
returns either a (virtual memory word aligned) pointer to it or C<NULL> in
case of an error (out of memory). It behaves like the POSIX.1 malloc(3)
function but instead of allocating memory from the I<heap> it allocates it
-from the shared memory segment underlaying I<mm>.
+from the shared memory segment underlying I<mm>.
=item void B<mm_free>(MM *I<mm>, void *I<ptr>);
This deallocates the chunk starting at I<ptr> in the shared memory pool I<mm>.
It behaves like the POSIX.1 free(3) function but instead of deallocating
memory from the I<heap> it deallocates it from the shared memory segment
-underlaying I<mm>.
+underlying I<mm>.
=item void *B<mm_realloc>(MM *I<mm>, void *I<ptr>, size_t I<size>);
This function reallocates the chunk starting at I<ptr> inside the shared
memory pool I<mm> with the new size of I<size> bytes. It behaves like the
POSIX.1 realloc(3) function but instead of reallocating memory in the
-I<heap> it reallocates it in the shared memory segment underlaying I<mm>.
+I<heap> it reallocates it in the shared memory segment underlying I<mm>.
=item void *B<mm_calloc>(MM *I<mm>, size_t I<number>, size_t I<size>);
@@ -498,7 +498,7 @@
=item int B<mm_core_permission>(void *I<core>, mode_t I<mode>, uid_t I<owner>, gid_t I<group>);
This sets the filesystem I<mode>, I<owner> and I<group> for the shared memory
-segment I<code> (has effects only when the underlaying shared memory segment
+segment I<code> (has effects only when the underlying shared memory segment
implementation is actually based on external auxiliary files). The arguments
are directly passed through to chmod(2) and chown(2).
@@ -536,7 +536,7 @@
=item size_t B<mm_core_align2page>(size_t I<size>);
This is just a utility function which can be used to align the number I<size>
-to the next virtual memory I<page> boundary used by the underlaying platform.
+to the next virtual memory I<page> boundary used by the underlying platform.
The memory page boundary under Unix platforms is usually somewhere between
2048 and 16384 bytes. You do not have to align the I<size> arguments of other
B<OSSP mm> library functions yourself, because this is already done internally.
@@ -546,12 +546,12 @@
=item size_t B<mm_core_align2word>(size_t I<size>);
This is another utility function which can be used to align the number I<size>
-to the next virtual memory I<word> boundary used by the underlaying platform.
+to the next virtual memory I<word> boundary used by the underlying platform.
The memory word boundary under Unix platforms is usually somewhere between 4
and 16 bytes. You do not have to align the I<size> arguments of other B<OSSP mm>
library functions yourself, because this is already done internally. This
function is exported by the B<OSSP mm> library just for convenience reasons in case
-an application wants to perform simular calculations for other purposes.
+an application wants to perform similar calculations for other purposes.
=back
@@ -584,16 +584,16 @@
=head1 RESTRICTIONS
The maximum size of a continuous shared memory segment one can allocate
-depends on the underlaying platform. This cannot be changed, of course. But
+depends on the underlying platform. This cannot be changed, of course. But
currently the high-level malloc(3)-style API just uses a single shared memory
-segment as the underlaying data structure for an C<MM> object which means that
+segment as the underlying data structure for an C<MM> object which means that
the maximum amount of memory an C<MM> object represents also depends on the
platform.
This could be changed in later versions by allowing at least the
high-level malloc(3)-style API to internally use multiple shared memory
segments to form the C<MM> object. This way C<MM> objects could have
-arbitrary sizes, although the maximum size of an allocatable continous
+arbitrary sizes, although the maximum size of an allocatable continuous
chunk still is bounded by the maximum size of a shared memory segment.
=head1 SEE ALSO
|
