<para>&SBCL; supports a MetaObject Protocol which is intended to be
compatible with &AMOP;; present exceptions to this (as distinct from
<para>&SBCL; supports a MetaObject Protocol which is intended to be
compatible with &AMOP;; present exceptions to this (as distinct from
<itemizedlist>
<listitem><para>the abstract <classname>metaobject</> class is not
present in the class hierarchy;</para></listitem>
<itemizedlist>
<listitem><para>the abstract <classname>metaobject</> class is not
present in the class hierarchy;</para></listitem>
<listitem><para>the system-supplied <property>:around</> method for
<function>compute-slots</> specialized on
<classname>funcallable-standard-class</> does not respect the
<listitem><para>the system-supplied <property>:around</> method for
<function>compute-slots</> specialized on
<classname>funcallable-standard-class</> does not respect the
<para>&SBCL; (as of version 0.8.3, on Linux x86 only) supports a
fairly low-level threading interface that maps onto the host operating
<para>&SBCL; (as of version 0.8.3, on Linux x86 only) supports a
fairly low-level threading interface that maps onto the host operating
can be found in the <literal>sb-thread</literal> package. This is
intended for public consumption, so look at the exported symbols and
their documentation strings.
can be found in the <literal>sb-thread</literal> package. This is
intended for public consumption, so look at the exported symbols and
their documentation strings.
<para><function>sb-ext:quit</function> exits the current thread, not
necessarily the whole environment. The environment will be shut down
when the last thread exits.
<para><function>sb-ext:quit</function> exits the current thread, not
necessarily the whole environment. The environment will be shut down
when the last thread exits.
<para>Threads arbitrate between themselves for the user's attention.
A thread may be in one of three notional states: foreground,
<para>Threads arbitrate between themselves for the user's attention.
A thread may be in one of three notional states: foreground,
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.
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.
<para>If the user has multiple views onto the same Lisp image (for
example, using multiple terminals, or a windowing system, or network
<para>If the user has multiple views onto the same Lisp image (for
example, using multiple terminals, or a windowing system, or network
view has its own collection of foreground/background/stopped threads.
<function>sb-thread:make-listener-thread</function> can be used to
start a new thread in its own `session'.
view has its own collection of foreground/background/stopped threads.
<function>sb-thread:make-listener-thread</function> can be used to
start a new thread in its own `session'.
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. <command>ps</command> output.
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. <command>ps</command> output.
<para>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.
<para>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.
<para>Threads waiting on queues (e.g. for locks or condition
variables) are put to sleep using <function>sigtimedwait()</function>
and woken with SIGCONT.
<para>Threads waiting on queues (e.g. for locks or condition
variables) are put to sleep using <function>sigtimedwait()</function>
and woken with SIGCONT.
<para>&SBCL; at present will alway have at least two tasks running as
seen from Linux: when the first process has done startup
<para>&SBCL; at present will alway have at least two tasks running as
seen from Linux: when the first process has done startup
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.
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.
<para>Garbage collection is done with the existing Conservative
Generational GC. Allocation is done in small (typically 8k) regions :
<para>Garbage collection is done with the existing Conservative
Generational GC. Allocation is done in small (typically 8k) regions :
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.
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.
<para>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.
<para>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.
<para>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
<para>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
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 <varname>sb-thread::*session-lock*</varname>
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 <varname>sb-thread::*session-lock*</varname>
<para>A thread can be created in a new Lisp 'session' (new terminal or
window) using <function>sb-thread:make-listener-thread</function>.
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.
<para>A thread can be created in a new Lisp 'session' (new terminal or
window) using <function>sb-thread:make-listener-thread</function>.
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.
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.
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>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>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 -->