X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=doc%2Fbeyond-ansi.sgml;h=694898ad38e8801db088a54e65615e9c5052087f;hb=22c1de0a40df83bb5628974010a879cb2c17ff53;hp=e175fa439401e3a58201e5631242aee2b071f047;hpb=8e1eb3714554b8b93455895756787f6c4f63afc5;p=sbcl.git diff --git a/doc/beyond-ansi.sgml b/doc/beyond-ansi.sgml index e175fa4..694898a 100644 --- a/doc/beyond-ansi.sgml +++ b/doc/beyond-ansi.sgml @@ -1,3 +1,4 @@ + Beyond The &ANSI; Standard</> <para>&SBCL; is mostly an implementation of the &ANSI; standard for @@ -47,7 +48,7 @@ of the same symbol more than once is undefined unless the new value is <function>eql</> to the old value. Conforming to this specification is a nuisance when the "constant" value is only constant under some weaker test like <function>string=</> or <function>equal</>. It's -especially annoying because <function>defconstant</> takes effect +especially annoying because, in &SBCL;, <function>defconstant</> takes effect not only at load time but also at compile time, so that just compiling and loading reasonable code like <programlisting>(defconstant +foobyte+ '(1 4))</> @@ -62,7 +63,11 @@ E.g., the code above can be given an exactly defined meaning by replacing <function>defconstant</> either with <function>defparameter</> or with a customized macro which does the right thing, possibly along the lines of the <function>defconstant-eqx</> macro used internally in the -implementation of SBCL itself.</para> +implementation of &SBCL; itself. In circumstances where this is not +appropriate, the programmer can handle the condition type +<errortype>sb-ext:defconstant-uneql</errortype>, and choose either the +<action>continue</action> or <action>abort</action> restart as +appropriate.</para> <para>&SBCL; gives style warnings about various kinds of perfectly legal code, e.g. @@ -117,15 +122,133 @@ whose instances can be used as Lisp streams (e.g. passed as the first argument to <function>format</>).</para> <para>&SBCL; supports a MetaObject Protocol which is intended to be -compatible with &AMOP;; exceptions to this (as distinct from current -bugs<!-- Such as the distinction between CL:FIND-CLASS and -SB-PCL::FIND-CLASS :-( -->) are that -<function>compute-effective-method</> only returns one value, not -two<!-- FIXME: anything else? What about extensions? (e.g. COMPUTE-SLOTS -behaviour) -->.</para> +compatible with &AMOP;; present exceptions to this (as distinct from +current bugs) are: +<itemizedlist> + <listitem><para>the abstract <classname>metaobject</> class is not + present in the class hierarchy;</para></listitem> + <listitem><para>the <classname>standard-object</> and + <classname>funcallable-standard-object</> classes are + disjoint;</para></listitem> + <listitem><para><function>compute-effective-method</> only returns + one value, not two;</para></listitem> + <listitem><para>the system-supplied <property>:around</> method for + <function>compute-slots</> specialized on + <classname>funcallable-standard-class</> does not respect the + requested order from a user-supplied primary method. +</itemizedlist> </sect2> +<sect2><title>Threading (a.k.a Multiprocessing)</> + +<para>&SBCL; (as of version 0.x.y, 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. + +<sect3><title>Lisp-level view + +A rudimentary interface to creating and managing multiple threads +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, +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. + +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. +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. + +Implementation (Linux x86) + +On Linux x86, this is implemented using +clone() and does not involve pthreads. This is +not because there is anything wrong with pthreads per +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 +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 is then used to run GC and to reap dead subthreads +when they exit. + +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 using ptrace(), so you +should be very careful if you wish to examine an &SBCL; worker thread +using strace, truss, +gdb or similar. It may be prudent to disable GC +before doing so. + +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 +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 &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</> <para>The UNIX command line can be read from the variable @@ -139,6 +262,17 @@ is also supported.</para> </sect2> +<sect2><title>Customization Hooks for Users + +The behaviour of require when called with only +one argument is implementation-defined. In &SBCL; it calls functions +on the user-settable list sb-ext:*module-provider-functions* +- see the require documentation string for details. + +The toplevel repl prompt may be customized, and the function +that reads user input may be replaced completely. + Tools To Help Developers &SBCL; provides a profiler and other extensions to the &ANSI; @@ -202,11 +336,9 @@ fixed addresses, a precondition for using copy-on-write to share code between multiple Lisp processes. is less important with modern generational garbage collectors. -The sb-ext:truly-the operator does what the -cl:the operator does in a more conventional -implementation of &CommonLisp;, declaring the type of its argument -without any runtime checks. (Ordinarily in &SBCL;, any type -declaration is treated as an assertion and checked at runtime.) +The sb-ext:truly-the declares the type of the +result of the operations, producing its argument; the declaration is +not checked. In short: don't use it. The sb-ext:freeze-type declaration declares that a type will never change, which can make type testing @@ -219,9 +351,11 @@ to it. This is appropriate for functions like sqrt, but is not appropriate for functions like aref, which can change their return values when the underlying data are changed. + - \ No newline at end of file +