summaryrefslogtreecommitdiffstats
path: root/docs/nspr/reference/pr_setconcurrency.rst
diff options
context:
space:
mode:
authorDaniel Baumann <daniel.baumann@progress-linux.org>2024-04-07 17:32:43 +0000
committerDaniel Baumann <daniel.baumann@progress-linux.org>2024-04-07 17:32:43 +0000
commit6bf0a5cb5034a7e684dcc3500e841785237ce2dd (patch)
treea68f146d7fa01f0134297619fbe7e33db084e0aa /docs/nspr/reference/pr_setconcurrency.rst
parentInitial commit. (diff)
downloadthunderbird-6bf0a5cb5034a7e684dcc3500e841785237ce2dd.tar.xz
thunderbird-6bf0a5cb5034a7e684dcc3500e841785237ce2dd.zip
Adding upstream version 1:115.7.0.upstream/1%115.7.0upstream
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
Diffstat (limited to 'docs/nspr/reference/pr_setconcurrency.rst')
-rw-r--r--docs/nspr/reference/pr_setconcurrency.rst42
1 files changed, 42 insertions, 0 deletions
diff --git a/docs/nspr/reference/pr_setconcurrency.rst b/docs/nspr/reference/pr_setconcurrency.rst
new file mode 100644
index 0000000000..309a0312bc
--- /dev/null
+++ b/docs/nspr/reference/pr_setconcurrency.rst
@@ -0,0 +1,42 @@
+PR_SetConcurrency
+=================
+
+Creates extra virtual processor threads. Generally used with MP systems.
+
+
+Syntax
+------
+
+.. code::
+
+ #include <prinit.h>
+
+ void PR_SetConcurrency(PRUintn numCPUs);
+
+
+Parameter
+~~~~~~~~~
+
+:ref:`PR_SetConcurrency` has one parameter:
+
+``numCPUs``
+ The number of extra virtual processor threads to be created.
+
+
+Description
+-----------
+
+Setting concurrency controls the number of virtual processors that NSPR
+uses to implement its ``M x N`` threading model. The ``M x N`` model is
+not available on all host systems. On those where it is not available,
+:ref:`PR_SetConcurrency` is ignored.
+
+Virtual processors are actually\ *global* threads, each of which is
+designed to support an arbitrary number of\ *local* threads. Since
+global threads are scheduled by the host operating system, this model is
+particularly applicable to multiprocessor architectures, where true
+parallelism is possible. However, it may also prove advantageous on
+uniprocessor systems to reduce the impact of having a locally scheduled
+thread calling incidental blocking functions. In such cases, all the
+threads being supported by the virtual processor will block, but those
+assigned to another virtual processor will be unaffected.