mirror of
https://git.tukaani.org/xz.git
synced 2024-04-04 12:36:23 +02:00
Bunch of grammar fixes from meyering.
This commit is contained in:
parent
dc192b6343
commit
11de5d5267
4 changed files with 9 additions and 9 deletions
|
@ -86,7 +86,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
|
||||
For more portable and fine-grained limiting, you can use
|
||||
memory limiter functions found from <lzma/memlimit.h>.
|
||||
|
||||
|
||||
|
@ -121,7 +121,7 @@ Using liblzma securely
|
|||
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
|
||||
Memory-limiting 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_limiter. The drawback is that if one Block
|
||||
|
@ -132,7 +132,7 @@ Using liblzma securely
|
|||
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.
|
||||
- You use a maximum of n threads.
|
||||
- x(i) is the decoder memory requirements of the Block number i
|
||||
in an expected input Stream.
|
||||
- The memory limiter is set to higher value than the sum of n
|
||||
|
@ -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_limiter for each thread" solution, possibly fallbacking
|
||||
lzma_memory_limiter for each thread" solution, possibly falling back
|
||||
to single-threaded mode in case the per-thread memory limits aren't
|
||||
enough in multi-threaded mode.
|
||||
|
||||
|
|
|
@ -22,7 +22,7 @@
|
|||
|
||||
|
||||
/**
|
||||
* \brief Opaque data type used with the memory usage limitting functions
|
||||
* \brief Opaque data type used with the memory usage limiting functions
|
||||
*/
|
||||
typedef struct lzma_memlimit_s lzma_memlimit;
|
||||
|
||||
|
@ -39,7 +39,7 @@ typedef struct lzma_memlimit_s lzma_memlimit;
|
|||
* to these functions can be used in lzma_allocator structure, which makes
|
||||
* it easy to limit memory usage with liblzma.
|
||||
*
|
||||
* The memory limiter functions are not tied to limitting memory usage
|
||||
* The memory limiter functions are not tied to limiting memory usage
|
||||
* with liblzma itself. You can use them with anything you like.
|
||||
*
|
||||
* In multi-threaded applications, only one thread at once may use the same
|
||||
|
@ -161,7 +161,7 @@ extern void *lzma_memlimit_alloc(
|
|||
|
||||
|
||||
/**
|
||||
* \brief Removes the pointer from memory limitting list
|
||||
* \brief Removes the pointer from memory limiting list
|
||||
*
|
||||
* \param mem Pointer to a lzma_memlimit structure returned
|
||||
* earlier by lzma_memry_limit_create().
|
||||
|
|
|
@ -124,7 +124,7 @@ These aren't implemented yet.
|
|||
" Resource usage options:\n"
|
||||
"\n"
|
||||
" -M, --memory=NUM use roughly NUM bytes of memory at maximum\n"
|
||||
" -T, --threads=NUM use at maximum of NUM (de)compression threads\n"
|
||||
" -T, --threads=NUM use a maximum of NUM (de)compression threads\n"
|
||||
// " --threading=STR threading style; possible values are `auto' (default),\n"
|
||||
// " `files', and `stream'
|
||||
));
|
||||
|
|
|
@ -25,7 +25,7 @@
|
|||
specification, but try to trigger excessive CPU, RAM or disk usage in
|
||||
the decoder. To prevent malicious files from putting the decoder in
|
||||
inifinite loop (*), eating all available RAM or disk space, decoders
|
||||
should have internal limitters that catch these situations.
|
||||
should have internal limiters that catch these situations.
|
||||
|
||||
(*) Strictly speaking not infinite, but if decoding of a small file
|
||||
would take a few weeks or even years, it's an infinite loop in
|
||||
|
|
Loading…
Reference in a new issue