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
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
|
<?xml version="1.0" encoding="ISO-8859-1" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" /><title>Extensions</title><meta name="generator" content="DocBook XSL Stylesheets V1.62.4" /><link rel="home" href="index.html" title="SBCL User Manual" /><link rel="up" href="beyond-ansi.html" title="Chapter4.Beyond The ANSI Standard" /><link rel="previous" href="idiosyncrasies.html" title="Idiosyncrasies" /><link rel="next" href="ffi.html" title="Chapter5.The Foreign Function Interface" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Extensions</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="idiosyncrasies.html">Prev</a></td><th width="60%" align="center">Chapter4.Beyond The ANSI Standard</th><td width="20%" align="right"><a accesskey="n" href="ffi.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="extensions"></a>Extensions</h2></div></div><div></div></div><p><span class="application">SBCL</span> is derived from <span class="application">CMU CL</span>, which implements many extensions
to the <span class="acronym">ANSI</span> standard. <span class="application">SBCL</span> doesn't support as many extensions as
<span class="application">CMU CL</span>, but it still has quite a few.</p><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2965926"></a>Things Which Might Be In The Next <span class="acronym">ANSI</span> Standard</h3></div></div><div></div></div><p><span class="application">SBCL</span> provides extensive support for
calling external C code, described
<a href="ffi.html" title="Chapter5.The Foreign Function Interface">in its own chapter</a>.</p><p><span class="application">SBCL</span> provides additional garbage collection functionality not
specified by <span class="acronym">ANSI</span>. Weak pointers allow references to objects to be
maintained without keeping them from being GCed. And "finalization"
hooks are available to cause code to be executed when an object has been
GCed.</p><p><span class="application">SBCL</span> supports Gray streams, user-overloadable CLOS classes
whose instances can be used as Lisp streams (e.g. passed as the
first argument to <tt class="function">format</tt>). Additionally, the
bundled contrib module <span class="interface">sb-simple-streams</span>
implements a subset of the Franz Allegro simple-streams proposal.</p><p><span class="application">SBCL</span> supports a MetaObject Protocol which is intended to be
compatible with <span class="acronym">AMOP</span>; present exceptions to this (as distinct from
current bugs) are:</p><div class="itemizedlist"><ul type="disc"><li><p>the abstract <tt class="classname">metaobject</tt> class is not
present in the class hierarchy;</p></li><li><p>the <tt class="classname">standard-object</tt> and
<tt class="classname">funcallable-standard-object</tt> classes are
disjoint;</p></li><li><p><tt class="function">compute-effective-method</tt> only returns
one value, not two;</p></li><li><p>the system-supplied <span class="property">:around</span> method for
<tt class="function">compute-slots</tt> specialized on
<tt class="classname">funcallable-standard-class</tt> does not respect the
requested order from a user-supplied primary method.</p></li></ul></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2903670"></a>Threading (a.k.a Multiprocessing)</h3></div></div><div></div></div><p><span class="application">SBCL</span> (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. </p><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2903685"></a>Lisp-level view</h4></div></div><div></div></div><p>A rudimentary interface to creating and managing multiple threads
can be found in the <tt class="literal">sb-thread</tt> package. This is
intended for public consumption, so look at the exported symbols and
their documentation strings.
</p><p>Dynamic bindings to symbols are per-thread. Signal handlers
are per-thread.
</p><p><tt class="function">sb-ext:quit</tt> exits the current thread, not
necessarily the whole environment. The environment will be shut down
when the last thread exits.
</p><p>Threads arbitrate between themselves for the user's attention.
A thread may be in one of three notional states: foreground,
background, or stopped. When a background process attempts to print a
repl prompt or to enter the debugger, it will stop and print a message
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.
</p><p>If the user has multiple views onto the same Lisp image (for
example, using multiple terminals, or a windowing system, or network
access) they are typically set up as multiple `sessions' such that each
view has its own collection of foreground/background/stopped threads.
<tt class="function">sb-thread:make-listener-thread</tt> can be used to
start a new thread in its own `session'.
</p><p>Mutexes and condition variables are available for
managing access to shared data: see
</p><div class="itemizedlist"><ul type="disc"><li><pre class="programlisting">(apropos "mutex" :sb-thread)</pre></li><li><pre class="programlisting">(apropos "condition" :sb-thread)</pre></li><li><p>and the <span class="structname">waitqueue</span> structure
</p></li></ul></div><p>
and poke around in their documentation strings.</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2903780"></a>Implementation (Linux x86)</h4></div></div><div></div></div><p>On Linux x86, this is implemented using
<tt class="function">clone()</tt> and does not involve pthreads. This is
not because there is anything wrong with pthreads <span class="emphasis"><em>per
se</em></span>, but there is plenty wrong (from our perspective) with
LinuxThreads. <span class="application">SBCL</span> 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. <span><b class="command">ps</b></span> output.
</p><p>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.
</p><p>Threads waiting on queues (e.g. for locks or condition
variables) are put to sleep using <tt class="function">sigtimedwait()</tt>
and woken with SIGCONT.
</p><p><span class="application">SBCL</span> at present will alway have at least two tasks running as
seen from Linux: when the first process has done startup
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.
</p><p>Garbage collection is done with the existing Conservative
Generational GC. Allocation is done in small (typically 8k) regions :
each thread has its own region so this involves no stopping. However,
when a region fills, a lock must be obtained while another is
allocated, and when a collection is required, all processes are
stopped. This is achieved by sending them signals, which may make for
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.
</p><p>Large amounts of the <span class="application">SBCL</span> 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.
</p><p>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
on keyboard interrupt handling: pressing your terminal's intr key
(typically Control-C) will interrupt all processes in the foreground
process group, including Lisp threads that <span class="application">SBCL</span> 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 <tt class="varname">sb-thread::*session-lock*</tt>
</p><p>A thread can be created in a new Lisp 'session' (new terminal or
window) using <tt class="function">sb-thread:make-listener-thread</tt>.
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.
</p></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2924058"></a>Support For Unix</h3></div></div><div></div></div><p>The UNIX command line can be read from the variable
<tt class="varname">sb-ext:*posix-argv*</tt>. The UNIX environment can be queried with the
<tt class="function">sb-ext:posix-getenv</tt> function.</p><p>The <span class="application">SBCL</span> system can be terminated with <tt class="function">sb-ext:quit</tt>,
optionally returning a specified numeric value to the calling Unix
process. The normal Unix idiom of terminating on end of file on input
is also supported.</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2904538"></a>Customization Hooks for Users</h3></div></div><div></div></div><p>The behaviour of <tt class="function">require</tt> when called with only
one argument is implementation-defined. In <span class="application">SBCL</span> it calls functions
on the user-settable list <tt class="varname">sb-ext:*module-provider-functions*</tt>
- see the <tt class="function">require</tt> documentation string for details.
</p><p>The toplevel repl prompt may be customized, and the function
that reads user input may be replaced completely.
</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2904568"></a>Tools To Help Developers</h3></div></div><div></div></div><p><span class="application">SBCL</span> provides a profiler and other extensions to the <span class="acronym">ANSI</span>
<tt class="function">trace</tt> facility. See the online function documentation for
<tt class="function">trace</tt> for more information.</p><p>The debugger supports a number of options. Its documentation is
accessed by typing <b class="userinput"><tt>help</tt></b> at the debugger prompt.</p><p>Documentation for <tt class="function">inspect</tt> is accessed by typing
<b class="userinput"><tt>help</tt></b> at the <tt class="function">inspect</tt> prompt.</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2904625"></a>Interface To Low-Level <span class="application">SBCL</span> Implementation</h3></div></div><div></div></div><p><span class="application">SBCL</span> has the ability to save its state as a file for later
execution. This functionality is important for its bootstrapping
process, and is also provided as an extension to the user See the
documentation for <tt class="function">sb-ext:save-lisp-and-die</tt> for more
information.</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p><span class="application">SBCL</span> has inherited from <span class="application">CMU CL</span> various hooks to allow
the user to tweak and monitor the garbage collection process. These
are somewhat stale code, and their interface might need to be cleaned
up. If you have urgent need of them, look at the code in
<tt class="filename">src/code/gc.lisp</tt> and bring it up on the
developers' mailing list.</p></div><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p><span class="application">SBCL</span> has various hooks inherited from <span class="application">CMU CL</span>, like
<tt class="function">sb-ext:float-denormalized-p</tt>, to allow a program to take
advantage of <span class="acronym">IEEE</span> floating point arithmetic properties which aren't
conveniently or efficiently expressible using the <span class="acronym">ANSI</span> standard. These
look good, and their interface looks good, but <span class="acronym">IEEE</span> support is
slightly broken due to a stupid decision to remove some support for
infinities (because it wasn't in the <span class="acronym">ANSI</span> spec and it didn't occur to
me that it was in the <span class="acronym">IEEE</span> spec). If you need this stuff, take a look
at the code and bring it up on the developers' mailing
list.</p></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2904706"></a>Efficiency Hacks</h3></div></div><div></div></div><p>The <tt class="function">sb-ext:purify</tt> function causes <span class="application">SBCL</span>
first to collect all garbage, then to mark all uncollected objects as
permanent, never again attempting to collect them as garbage. This can
cause a large increase in efficiency when using a primitive garbage
collector, or a more moderate increase in efficiency when using a more
sophisticated garbage collector which is well suited to the program's
memory usage pattern. It also allows permanent code to be frozen at
fixed addresses, a precondition for using copy-on-write to share code
between multiple Lisp processes. is less important with modern
generational garbage collectors. </p><p>The <tt class="function">sb-ext:truly-the</tt> declares the type of the
result of the operations, producing its argument; the declaration is
not checked. In short: don't use it.</p><p>The <tt class="function">sb-ext:freeze-type</tt> declaration declares that a
type will never change, which can make type testing
(<tt class="function">typep</tt>, etc.) more efficient for structure types.</p><p>The <tt class="function">sb-ext:constant-function</tt> declaration specifies
that a function will always return the same value for the same
arguments, which may allow the compiler to optimize calls
to it. This is appropriate for functions like <tt class="function">sqrt</tt>, but
is <span class="emphasis"><em>not</em></span> appropriate for functions like <tt class="function">aref</tt>,
which can change their return values when the underlying data are
changed.</p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="idiosyncrasies.html">Prev</a></td><td width="20%" align="center"><a accesskey="u" href="beyond-ansi.html">Up</a></td><td width="40%" align="right"><a accesskey="n" href="ffi.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Idiosyncrasies</td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top">Chapter5.The Foreign Function Interface</td></tr></table></div></body></html>
|
