X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=doc%2Fbeyond-ansi.sgml;h=c29fd52e68bef1d1b2e4a426b7a600516b5eb832;hb=592ecf78ec904eea390ca67dbacf00d486276c58;hp=afc3962f13047501c2178659bae978592a645041;hpb=d4e910b9a2851d52117c4c7fd9f847e5b54414a0;p=sbcl.git
diff --git a/doc/beyond-ansi.sgml b/doc/beyond-ansi.sgml
index afc3962..c29fd52 100644
--- a/doc/beyond-ansi.sgml
+++ b/doc/beyond-ansi.sgml
@@ -125,7 +125,7 @@ implements a subset of the Franz Allegro simple-streams proposal.
&SBCL; supports a MetaObject Protocol which is intended to be
compatible with &AMOP;; present exceptions to this (as distinct from
-current bugs) are:
+current bugs) are:
the abstract metaobject class is not
present in the class hierarchy;
@@ -137,7 +137,8 @@ current bugs) are:
the system-supplied :around method for
compute-slots specialized on
funcallable-standard-class does not respect the
- requested order from a user-supplied primary method.
+ requested order from a user-supplied primary method.
+
@@ -146,7 +147,7 @@ current bugs) are:
&SBCL; (as of version 0.8.3, on Linux x86 only) supports a
fairly low-level threading interface that maps onto the host operating
-system's concept of threads or lightweight processes.
+system's concept of threads or lightweight processes.
Lisp-level view
@@ -154,13 +155,16 @@ system's concept of threads or lightweight processes.
can be found in the sb-thread package. This is
intended for public consumption, so look at the exported symbols and
their documentation strings.
+
Dynamic bindings to symbols are per-thread. Signal handlers
are per-thread.
+
sb-ext:quit exits the current thread, not
necessarily the whole environment. The environment will be shut down
when the last thread exits.
+
Threads arbitrate between themselves for the user's attention.
A thread may be in one of three notional states: foreground,
@@ -170,6 +174,7 @@ saying that it has stopped. The user at his leisure may switch to
that thread to find out what it needs. If a background thread enters
the debugger, selecting any restart will put it back into the
background before it resumes.
+
If the user has multiple views onto the same Lisp image (for
example, using multiple terminals, or a windowing system, or network
@@ -177,21 +182,23 @@ access) they are typically set up as multiple `sessions' such that each
view has its own collection of foreground/background/stopped threads.
sb-thread:make-listener-thread can be used to
start a new thread in its own `session'.
+
Mutexes and condition variables are available for
managing access to shared data: see
-
(apropos "mutex" :sb-thread)
+
(apropos "condition" :sb-thread)
+
and the waitqueue structure
-
-and poke around in their documentation strings.
+and poke around in their documentation strings.
+
Implementation (Linux x86)
@@ -202,16 +209,19 @@ se, but there is plenty wrong (from our perspective) with
LinuxThreads. &SBCL; threads are mapped 1:1 onto Linux tasks which
share a VM but nothing else - each has its own process id and can be
seen in e.g. ps output.
+
Per-thread local bindings for special variables is achieved
using the %fs segment register to point to a per-thread storage area.
This may cause interesting results if you link to foreign code that
expects threading or creates new threads, and the thread library in
question uses %fs in an incompatible way.
+
Threads waiting on queues (e.g. for locks or condition
variables) are put to sleep using sigtimedwait()
and woken with SIGCONT.
+
&SBCL; at present will alway have at least two tasks running as
seen from Linux: when the first process has done startup
@@ -219,6 +229,7 @@ initialization (mapping files in place, installing signal handlers
etc) it creates a new thread to run the Lisp startup and initial
listener. The original thread stays around to reap dead subthreads
and deallocate their resources (e.g. stacks) when they exit.
+
Garbage collection is done with the existing Conservative
Generational GC. Allocation is done in small (typically 8k) regions :
@@ -230,11 +241,13 @@ interesting behaviour if they are interrupted in system calls. The
streams interface is believed to handle the required system call
restarting correctly, but this may be a consideration when making
other blocking calls e.g. from foreign library code.
+
Large amounts of the &SBCL; library have not been inspected for
thread-safety. Some of the obviously unsafe areas have large locks
around them, so compilation and fasl loading, for example, cannot be
parallelized. Work is ongoing in this area.
+
A new thread by default is created in the same POSIX process
group and session as the thread it was created by. This has an impact
@@ -244,12 +257,18 @@ process group, including Lisp threads that &SBCL; considers to be
notionally `background'. This is undesirable, so background threads
are set to ignore the SIGINT signal. Arbitration for the input stream
is managed by locking on sb-thread::*session-lock*
+
A thread can be created in a new Lisp 'session' (new terminal or
window) using sb-thread:make-listener-thread.
These sessions map directly onto POSIX sessions, so that pressing
Control-C in the wrong window will not interrupt them - this has been
found to be embarrassing.
+
+
+
+
+
Support For Unix</>
@@ -270,10 +289,14 @@ is also supported.</para>
one argument is implementation-defined. In &SBCL; it calls functions
on the user-settable list <varname>sb-ext:*module-provider-functions*</varname>
- see the <function>require</function> documentation string for details.
+</para>
<para>The toplevel repl prompt may be customized, and the function
that reads user input may be replaced completely. <!-- FIXME but I
don't currently remember how -->
+</para>
+
+</sect2>
<sect2><title>Tools To Help Developers