summaryrefslogtreecommitdiffstats
path: root/docs/nspr/reference/prthreadscope.rst
blob: c468704295125bacdfa2f3c0b07577d562fba61f (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
PRThreadScope
=============

The scope of an NSPR thread, specified as a parameter to
:ref:`PR_CreateThread` or returned by :ref:`PR_GetThreadScope`.


Syntax
------

.. code::

   #include <prthread.h>

   typedef enum PRThreadScope {
      PR_LOCAL_THREAD,
      PR_GLOBAL_THREAD
      PR_GLOBAL_BOUND_THREAD
   } PRThreadScope;


Enumerators
~~~~~~~~~~~

``PR_LOCAL_THREAD``
   A local thread, scheduled locally by NSPR within the process.
``PR_GLOBAL_THREAD``
   A global thread, scheduled by the host OS.
``PR_GLOBAL_BOUND_THREAD``
   A global bound (kernel) thread, scheduled by the host OS


Description
-----------

An enumerator of type :ref:`PRThreadScope` specifies how a thread is
scheduled: either locally by NSPR within the process (a local thread) or
globally by the host (a global thread).

Global threads are scheduled by the host OS and compete with all other
threads on the host OS for resources. They are subject to fairly
sophisticated scheduling techniques.

Local threads are scheduled by NSPR within the process. The process is
assumed to be globally scheduled, but NSPR can manipulate local threads
without system intervention. In most cases, this leads to a significant
performance benefit.

However, on systems that require NSPR to make a distinction between
global and local threads, global threads are invariably required to do
any form of I/O. If a thread is likely to do a lot of I/O, making it a
global thread early is probably warranted.

On systems that don't make a distinction between local and global
threads, NSPR silently ignores the scheduling request. To find the scope
of the thread, call :ref:`PR_GetThreadScope`.