~ubuntu-branches/ubuntu/precise/kompozer/precise

« back to all changes in this revision

Viewing changes to mozilla/nsprpub/pr/src/threads/combined/README

  • Committer: Bazaar Package Importer
  • Author(s): Anthony Yarusso
  • Date: 2007-08-27 01:11:03 UTC
  • Revision ID: james.westby@ubuntu.com-20070827011103-2jgf4s6532gqu2ka
Tags: upstream-0.7.10
ImportĀ upstreamĀ versionĀ 0.7.10

Show diffs side-by-side

added added

removed removed

Lines of Context:
 
1
NSPR 2.0 evolution
 
2
------------------
 
3
 
 
4
 
 
5
Phase 1- today
 
6
 
 
7
Currently (Oct 10, 1996) NSPR 2.0 has two modes.  Either _PR_NTHREAD 
 
8
is defined, in which case the PR_CreateThread() call always creates a 
 
9
native kernel thread, or _PR_NTHREAD is not defined and PR_CreateThread() 
 
10
always creates user level threads within the single, original process.  This 
 
11
source code is reflected in two directories, nspr20/pr/src/threads/native, and 
 
12
nspr20/pr/src/threads/user.  Although the PR_CreateThread() function has
 
13
a paramter to specify the "scope" of a thread, this parameter is not yet 
 
14
used- except on solaris where it uses it to specify bound vs unbound threads.
 
15
 
 
16
Phase 2 - next week
 
17
 
 
18
The next step is to provide a combination of user and native threads.  The
 
19
idea, of course, is to have some small number of native threads and each of 
 
20
those threads be able to run user level threads.  The number of native
 
21
threads created will most likely be proportional to the number of CPUs in
 
22
the system.  For this reason, the specific set of native threads which are
 
23
used to run the user-level threads will be called "CPU" threads.  
 
24
 
 
25
The user level threads which will be run on the CPU threads are able to
 
26
run on any of the CPU threads available, and over the course of a user-level
 
27
thread's lifetime, it may drift from one CPU thread to another.  All 
 
28
user-level threads will compete for processing time via a single run queue.
 
29
 
 
30
Creation of a CPU thread will be primarily controlled by NSPR itself or by
 
31
the user running a function PR_Concurrency().  The details of PR_Concurrency()
 
32
have not yet been worked out; but the idea is that the user can specify to 
 
33
NSPR how many CPU threads are desired.
 
34
 
 
35
In this system, user-level threads are created by using PR_CreateThread() and
 
36
specifying the PR_LOCAL_SCOPE option.  LOCAL_SCOPE indicates that the thread
 
37
will be under the control of the "local" scheduler.  Creating threads with
 
38
GLOBAL_SCOPE, on the other hand will create a thread which is under the 
 
39
control of the system's scheduler.  In otherwords, this creates a native thread
 
40
which is not a CPU thread; it runs a single thread task and never has more 
 
41
than one task to run.  LOCAL_SCOPE is much like creating a Solaris unbound 
 
42
thread, while GLOBAL_SCOPE is similar to creating a Solaris bound thread.
 
43
 
 
44
To implement this architecture, the source code will still maintain the "user"
 
45
and "native" directories which is has today.  However a third directory 
 
46
"combined" will also exist.  To compile a version of NSPR which only creates
 
47
native threads, the user can define _PR_NTHREAD.  For exclusive user-level
 
48
threads, do not define _PR_NTHREAD.  To get the combined threads, define
 
49
_PR_NTHREAD and _PR_USE_CPUS.
 
50
 
 
51
 
 
52
Phase 3 - later than next week
 
53
 
 
54
The goal is to eliminate the 3 directories.  Once these three models are in
 
55
place, the remaining work will be to eliminate the native and user thread
 
56
directories for all platforms, so that the entire thread model is contained
 
57
within what is today called the "combined" model.  This new and glorious
 
58
source code will attempt to make the "combined" model on any platforms which
 
59
provide the necessary underlying native threading, but will also be 
 
60
capable of using exclusive user-level threads on systems which don't have
 
61
native threads.
 
62