static/README.wasm.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
New commits:
commit 566fbd5cc3b56fdfae88274e6f01fa3451cc1b79
Author: Andrea Gelmini <andrea.gelm...@gelma.net>
AuthorDate: Thu Jul 25 09:03:27 2024 +0200
Commit: Julien Nabet <serval2...@yahoo.fr>
CommitDate: Thu Jul 25 11:15:49 2024 +0200
Fix typo
Change-Id: I465502f90e0ce458f6746efa6e558896f6bea5ab
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170999
Reviewed-by: Julien Nabet <serval2...@yahoo.fr>
Tested-by: Jenkins
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.
