aboutsummaryrefslogtreecommitdiff
path: root/doc/liblzma-security.txt
diff options
context:
space:
mode:
authorLasse Collin <lasse.collin@tukaani.org>2008-04-28 17:06:34 +0300
committerLasse Collin <lasse.collin@tukaani.org>2008-04-28 17:06:34 +0300
commit3be21fb12f4cec2cf07799e8960382f4cb375369 (patch)
treea20ea08ae1eb3237a73cc68c2f0828a57f56e381 /doc/liblzma-security.txt
parentPrevent LZ encoder from hanging with known uncompressed (diff)
downloadxz-3be21fb12f4cec2cf07799e8960382f4cb375369.tar.xz
Fixed wrong spelling "limitter" to "limiter". This affects
liblzma's API.
Diffstat (limited to '')
-rw-r--r--doc/liblzma-security.txt14
1 files changed, 7 insertions, 7 deletions
diff --git a/doc/liblzma-security.txt b/doc/liblzma-security.txt
index 487637ed..78947bd8 100644
--- a/doc/liblzma-security.txt
+++ b/doc/liblzma-security.txt
@@ -87,7 +87,7 @@ Using liblzma securely
The simplest solution is to use setrlimit() if the kernel supports
RLIMIT_AS, which limits the memory usage of the whole process.
For more portable and fine-grained limitting, you can use
- memory limitter functions found from <lzma/memlimit.h>.
+ memory limiter functions found from <lzma/memlimit.h>.
1.2.1. Encoder
@@ -118,24 +118,24 @@ Using liblzma securely
1.2.2. Decoder
- A single-threaded decoder should simply use a memory limitter and
+ A single-threaded decoder should simply use a memory limiter and
indicate an error if it runs out of memory.
Memory-limitting with multi-threaded decoding is tricky. The simple
solution is to divide the maximum allowed memory usage with the
maximum allowed threads, and give each Block decoder their own
- independent lzma_memory_limitter. The drawback is that if one Block
+ independent lzma_memory_limiter. The drawback is that if one Block
needs notably more RAM than any other Block, the decoder will run out
of memory when in reality there would be plenty of free RAM.
- An attractive alternative would be using shared lzma_memory_limitter.
+ An attractive alternative would be using shared lzma_memory_limiter.
Depending on the application and the expected type of input, this may
either be the best solution or a source of hard-to-repeat problems.
Consider the following requirements:
- You use at maximum of n threads.
- x(i) is the decoder memory requirements of the Block number i
in an expected input Stream.
- - The memory limitter is set to higher value than the sum of n
+ - The memory limiter is set to higher value than the sum of n
highest values x(i).
(If you are better at explaining the above conditions, please
@@ -150,7 +150,7 @@ Using liblzma securely
Most .lzma files have all the Blocks encoded with identical settings,
or at least the memory usage won't vary dramatically. That's why most
multi-threaded decoders probably want to use the simple "separate
- lzma_memory_limitter for each thread" solution, possibly fallbacking
+ lzma_memory_limiter for each thread" solution, possibly fallbacking
to single-threaded mode in case the per-thread memory limits aren't
enough in multi-threaded mode.
@@ -206,7 +206,7 @@ FIXME: Memory usage of Stream info.
creating a denial of service like piping decoded a Data Block to
another process would do.
- At first it would seem that using a memory limitter would prevent
+ At first it would seem that using a memory limiter would prevent
this issue as a side effect. But it does so only if the application
requests liblzma to allocate the Extra Records and provide them to
the application. If Extra Records aren't requested, they aren't