+=head1 Different implementations of threads
+
+Some background on thread implementations from the operating system
+viewpoint. There are three basic categories of threads: user-mode threads,
+kernel threads, and multiprocessor kernel threads.
+
+User-mode threads are threads that live entirely within a program and
+its libraries. In this model, the OS knows nothing about threads. As
+far as it's concerned, your process is just a process.
+
+This is the easiest way to implement threads, and the way most OSes
+start. The big disadvantage is that, since the OS knows nothing about
+threads, if one thread blocks they all do. Typical blocking activities
+include most system calls, most I/O, and things like C<sleep()>.
+
+Kernel threads are the next step in thread evolution. The OS knows
+about kernel threads, and makes allowances for them. The main
+difference between a kernel thread and a user-mode thread is
+blocking. With kernel threads, things that block a single thread don't
+block other threads. This is not the case with user-mode threads,
+where the kernel blocks at the process level and not the thread level.
+
+This is a big step forward, and can give a threaded program quite a
+performance boost over non-threaded programs. Threads that block
+performing I/O, for example, won't block threads that are doing other
+things. Each process still has only one thread running at once,
+though, regardless of how many CPUs a system might have.
+
+Since kernel threading can interrupt a thread at any time, they will
+uncover some of the implicit locking assumptions you may make in your
+program. For example, something as simple as C<$x = $x + 2> can behave
+unpredictably with kernel threads if C<$x> is visible to other
+threads, as another thread may have changed C<$x> between the time it
+was fetched on the right hand side and the time the new value is
+stored.
+
+Multiprocessor kernel threads are the final step in thread
+support. With multiprocessor kernel threads on a machine with multiple
+CPUs, the OS may schedule two or more threads to run simultaneously on
+different CPUs.
+
+This can give a serious performance boost to your threaded program,
+since more than one thread will be executing at the same time. As a
+tradeoff, though, any of those nagging synchronization issues that
+might not have shown with basic kernel threads will appear with a
+vengeance.
+
+In addition to the different levels of OS involvement in threads,
+different OSes (and different thread implementations for a particular
+OS) allocate CPU cycles to threads in different ways.
+
+Cooperative multitasking systems have running threads give up control
+if one of two things happen. If a thread calls a yield function, it
+gives up control. It also gives up control if the thread does
+something that would cause it to block, such as perform I/O. In a
+cooperative multitasking implementation, one thread can starve all the
+others for CPU time if it so chooses.
+
+Preemptive multitasking systems interrupt threads at regular intervals
+while the system decides which thread should run next. In a preemptive
+multitasking system, one thread usually won't monopolize the CPU.
+
+On some systems, there can be cooperative and preemptive threads
+running simultaneously. (Threads running with realtime priorities
+often behave cooperatively, for example, while threads running at
+normal priorities behave preemptively.)
+
+Most modern operating systems support preemptive multitasking nowadays.
+
+=head1 Performance considerations
+
+The main thing to bear in mind when comparing Perl's I<ithreads> to other threading
+models is the fact that for each new thread created, a complete copy of
+all the variables and data of the parent thread has to be taken. Thus,
+thread creation can be quite expensive, both in terms of memory usage and
+time spent in creation. The ideal way to reduce these costs is to have a
+relatively short number of long-lived threads, all created fairly early
+on (before the base thread has accumulated too much data). Of course, this
+may not always be possible, so compromises have to be made. However, after
+a thread has been created, its performance and extra memory usage should
+be little different than ordinary code.
+
+Also note that under the current implementation, shared variables
+use a little more memory and are a little slower than ordinary variables.
+
+=head1 Process-scope Changes
+
+Note that while threads themselves are separate execution threads and
+Perl data is thread-private unless explicitly shared, the threads can
+affect process-scope state, affecting all the threads.
+
+The most common example of this is changing the current working
+directory using C<chdir()>. One thread calls C<chdir()>, and the working
+directory of all the threads changes.
+
+Even more drastic example of a process-scope change is C<chroot()>:
+the root directory of all the threads changes, and no thread can
+undo it (as opposed to C<chdir()>).
+
+Further examples of process-scope changes include C<umask()> and
+changing uids and gids.
+
+Thinking of mixing C<fork()> and threads? Please lie down and wait
+until the feeling passes. Be aware that the semantics of C<fork()> vary
+between platforms. For example, some Unix systems copy all the current
+threads into the child process, while others only copy the thread that
+called C<fork()>. You have been warned!
+
+Similarly, mixing signals and threads may be problematic.
+Implementations are platform-dependent, and even the POSIX
+semantics may not be what you expect (and Perl doesn't even
+give you the full POSIX API). For example, there is no way to
+guarantee that a signal sent to a multi-threaded Perl application
+will get intercepted by any particular thread. (However, a recently
+added feature does provide the capability to send signals between
+threads. See L<threads/THREAD SIGNALLING> for more details.)
+
+=head1 Thread-Safety of System Libraries
+
+Whether various library calls are thread-safe is outside the control
+of Perl. Calls often suffering from not being thread-safe include:
+C<localtime()>, C<gmtime()>, functions fetching user, group and
+network information (such as C<getgrent()>, C<gethostent()>,
+C<getnetent()> and so on), C<readdir()>, C<rand()>, and C<srand()>. In
+general, calls that depend on some global external state.
+
+If the system Perl is compiled in has thread-safe variants of such
+calls, they will be used. Beyond that, Perl is at the mercy of
+the thread-safety or -unsafety of the calls. Please consult your
+C library call documentation.
+
+On some platforms the thread-safe library interfaces may fail if the
+result buffer is too small (for example the user group databases may
+be rather large, and the reentrant interfaces may have to carry around
+a full snapshot of those databases). Perl will start with a small
+buffer, but keep retrying and growing the result buffer
+until the result fits. If this limitless growing sounds bad for
+security or memory consumption reasons you can recompile Perl with
+C<PERL_REENTRANT_MAXSIZE> defined to the maximum number of bytes you will
+allow.
+