diff options
| author | Andrea Gelmini <andrea.gelmini@gelma.net> | 2024-07-25 09:03:27 +0200 |
|---|---|---|
| committer | Julien Nabet <serval2412@yahoo.fr> | 2024-07-25 11:15:49 +0200 |
| commit | 566fbd5cc3b56fdfae88274e6f01fa3451cc1b79 (patch) | |
| tree | 2bb2ff1f021a767de2a424e81e2050efa2337be0 /static | |
| parent | 6817badaf268f49106406157cf5005871314dc32 (diff) | |
Fix typo
Change-Id: I465502f90e0ce458f6746efa6e558896f6bea5ab
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170999
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
Diffstat (limited to 'static')
| -rw-r--r-- | static/README.wasm.md | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/static/README.wasm.md b/static/README.wasm.md index 4aa2f592e6ef..a28a23efac67 100644 --- a/static/README.wasm.md +++ b/static/README.wasm.md @@ -352,7 +352,7 @@ Worker available. There are patterns (like, at the time of writing this, the configmgr::Components::WriteThread) where a pthread can get spawned and joined and then re-spawned (and re-joined) multiple times during a single VCL Task execution (i.e., without the JS main thread event loop having a chance to get in -between any of those operations). But as the underlying Emscripten ptherad exiting operations will +between any of those operations). But as the underlying Emscripten pthread exiting operations will therefore queue up, the pthread spawning operations will eventually run out of -sPTHREAD_POOL_SIZE pre-spawned JS Workers. The solution here is to change our pthread usage patterns accordingly, so that such pthreads are rather kept running than being joined and re-spawned. |