Menu
▾
▴
clisp-cvs Digest, Vol 38, Issue 30
|
From: <cli...@li...> - 2009-06-22 02:55:32
|
Send clisp-cvs mailing list submissions to cli...@li... To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/clisp-cvs or, via email, send a message with subject or body 'help' to cli...@li... You can reach the person managing the list at cli...@li... When replying, please edit your Subject line so it is more specific than "Re: Contents of clisp-cvs digest..." CLISP CVS commits for today Today's Topics: 1. clisp/src ChangeLog,1.6903,1.6904 type.lisp,1.82,1.83 (Vladimir Tzankov) 2. clisp/doc impext.xml,1.591,1.592 multithread.txt,1.14,1.15 (Vladimir Tzankov) 3. clisp/doc impext.xml,1.592,1.593 (Sam Steingold) 4. clisp/doc impext.xml,1.593,1.594 (Sam Steingold) 5. clisp/doc cl-ent.xml,1.139,1.140 (Sam Steingold) ---------------------------------------------------------------------- Message: 1 Date: Sun, 21 Jun 2009 13:47:05 +0000 From: Vladimir Tzankov <vt...@us...> Subject: clisp/src ChangeLog,1.6903,1.6904 type.lisp,1.82,1.83 To: cli...@li... Message-ID: <E1M...@dd...> Update of /cvsroot/clisp/clisp/src In directory ddv4jf1.ch3.sourceforge.com:/tmp/cvs-serv6591/src Modified Files: ChangeLog type.lisp Log Message: (thread, mutex, exemption) [MULTITHREAD]: use THREADS instead of MT as package name Index: ChangeLog =================================================================== RCS file: /cvsroot/clisp/clisp/src/ChangeLog,v retrieving revision 1.6903 retrieving revision 1.6904 diff -u -d -r1.6903 -r1.6904 --- ChangeLog 20 Jun 2009 14:14:50 -0000 1.6903 +++ ChangeLog 21 Jun 2009 13:47:03 -0000 1.6904 @@ -1,3 +1,8 @@ +2009-06-21 Vladimir Tzankov <vtz...@gm...> + + * type.lisp (thread, mutex, exemption) [MULTITHREAD]: use THREADS + instead of MT as package name + 2009-06-20 Vladimir Tzankov <vtz...@gm...> * spvw.d (create_thread) [WIN32_THREADS]: initialize thread's Index: type.lisp =================================================================== RCS file: /cvsroot/clisp/clisp/src/type.lisp,v retrieving revision 1.82 retrieving revision 1.83 diff -u -d -r1.82 -r1.83 --- type.lisp 19 Jun 2009 19:07:48 -0000 1.82 +++ type.lisp 21 Jun 2009 13:47:03 -0000 1.83 @@ -343,9 +343,9 @@ (lambda (x) (eq 'foreign-pointer (type-of x)))) ;; threads.lisp is loaded after this file, ;; so these symbols are not external yet -#+mt (def-atomic-type mt::thread mt::threadp) -#+mt (def-atomic-type mt::mutex mt::mutexp) -#+mt (def-atomic-type mt::exemption mt::exemptionp) +#+mt (def-atomic-type threads::thread threads::threadp) +#+mt (def-atomic-type threads::mutex threads::mutexp) +#+mt (def-atomic-type threads::exemption threads::exemptionp) (def-atomic-type VECTOR vectorp) (def-atomic-type PLIST (lambda (x) (multiple-value-bind (length tail) (list-length-dotted x) ------------------------------ Message: 2 Date: Sun, 21 Jun 2009 21:40:24 +0000 From: Vladimir Tzankov <vt...@us...> Subject: clisp/doc impext.xml,1.591,1.592 multithread.txt,1.14,1.15 To: cli...@li... Message-ID: <E1M...@dd...> Update of /cvsroot/clisp/clisp/doc In directory ddv4jf1.ch3.sourceforge.com:/tmp/cvs-serv13183/doc Modified Files: impext.xml multithread.txt Log Message: [MULTITHREAD]: move "not implement yet" stuff to multithread.txt Index: multithread.txt =================================================================== RCS file: /cvsroot/clisp/clisp/doc/multithread.txt,v retrieving revision 1.14 retrieving revision 1.15 diff -u -d -r1.14 -r1.15 --- multithread.txt 20 Jun 2009 14:08:42 -0000 1.14 +++ multithread.txt 21 Jun 2009 21:40:22 -0000 1.15 @@ -12,6 +12,53 @@ Alternatively, you can pass "--with-threads=flavor" to the top-level configure ("flavor" is one of POSIX_THREADS, WIN32_THREADS). +When building with gcc that does not support __thread qualifier for per thread +variables it's better to add to CFLAGS: -DUSE_CUSTOM_TLS=3 (or 2). Built +executable will be significantly faster than the one with default settings (if +we rely on OS API for thread local storage i.e. pthread_getspecific(). +See comments in: http://clisp.cvs.sourceforge.net/viewvc/*checkout*/clisp/clisp/src/lispbibl.d +Platforms on which gcc does not support __thread qualifier are (encountered +till now): MacOSX, Win32+mingw + DOCS: impbyte.xml:"gc-mt"; impext.xml:"mt" preview: http://clisp.podval.org/impnotes/mt.html http://clisp.podval.org/impnotes/gc-mt.html + +Follows a list of TODO items - everything after --NOT IMPLEMENTED YET-- is not +ready. + +Packages +-------- + +PACKAGE objects have internal mutex and are locked by INTERN before adding +a symbol (if FIND-SYMBOL fails). All modifications of internal package data +are guarded by this mutex. + +--NOT IMPLEMENTED YET-- +Currently there is one exception: USE-PACKAGE is not protected and thus not +thread safe. + +Symbol look-up within package currently is not guarded! This means that in +certain cases FIND-SYMBOL may return NIL even though the symbol is accessible +(this may happen when internal package hash tables are re-hashed at the time +FIND-SYMBOL performs look-up). + +TODO: Acquire lock(s) for every symbol look-up (may be very be expensive)? + Use rwlock? Better approach may be is to have lock free hash table + implementation? + +CLOS +---- + +DEFCLASS, DEFGENERIC, DEFMETHOD, DEFSTRUCT must get a global "DEF-CLOS" +lock because they change the global class hierarchy. +(This is a consequence of the Parallelizability Principle.) +--NOT IMPLEMENTED YET-- + + +WIN32 +----- + +--NOT IMPLEMENTED YET-- +Currently blocking I/O cannot be interrupted. The interrupt will be handled +after the call returns Index: impext.xml =================================================================== RCS file: /cvsroot/clisp/clisp/doc/impext.xml,v retrieving revision 1.591 retrieving revision 1.592 diff -u -d -r1.591 -r1.592 --- impext.xml 21 Jun 2009 09:51:27 -0000 1.591 +++ impext.xml 21 Jun 2009 21:40:21 -0000 1.592 @@ -4746,20 +4746,13 @@ PACKAGE objects have internal mutex and are locked by INTERN before adding a symbol (if FIND-SYMBOL fails). All modifications of internal package data are guarded by this mutex.</para> - <para>NB: currently there is one exception: &use-package; is not protected and - thus not thread safe.</para> - <para>NB: Symbol look-up within package currently is not guarded! This means - that in certain cases &find-symbol; may return &nil; even though the symbol - is accessible (this may happen when internal package hash tables are - re-hashed at the time &find-symbol; performs look-up). - TODO: Acquire lock(s) for every symbol look-up (may be very be expensive)? - Use rwlock? Better approach may be is to have lock free hash table - implementation? -</para></section> -<section id="mt-clos"><title>CLOS</title><para> - DEFCLASS, DEFGENERIC, DEFMETHOD, DEFSTRUCT must get a global "DEF-CLOS" - lock because they change the global class hierarchy. - --NOT IMPLEMENTED YET--</para></section> + <warning><para>Currently there is one exception: &use-package; is not protected and + thus not thread safe.</para></warning> + <warning><para>Symbol look-up within package currently is not guarded! This means + that in certain cases &find-symbol; may return &nil; even though the symbol + is accessible (this may happen when internal package hash tables are + re-hashed at the time &find-symbol; performs look-up).</para></warning> +</section> <section id="mt-mutable"><title>Hash Tables, Sequences, and other mutable objects</title> @@ -4831,7 +4824,7 @@ funcall &func-r; (with parameters). Thread cannot be interrupted at any point - only at ones where GC can run - see <xref linkend="gc-mt"/>. </simpara><simpara>Currently on WIN32 blocking I/O cannot be interrupted. The - interrupt will be handled after the call returns (TODO: fix it) + interrupt will be handled after the call returns. </simpara><warning><para> Thread may be interrupted inside &unwind-protect;'s cleanup forms and on non-local exit from &func-r; - they may not execute entirely. In order to prevent this @@ -4872,12 +4865,9 @@ <varlistentry id="mutex-lock"><term><code>(&mutex-lock; &mutex-r; &key-amp; &timeout-k;)</code></term> <listitem><simpara>Acquire mutex. If mutex is owned by another thread - the - call blocks and waits up to &timeout-k; &seconds; (which may be a - non-negative &real-t; or a list <literal role="data">(sec usec)</literal> - or a pair <literal role="data">(sec . usec)</literal>). If timeout is not - specified - waits forever. - If mutex is non-recursive and calling thread owns it - error will be - signaled (otherwise will deadlock). + call blocks and waits up to &timeout-k; &seconds;. If timeout is not + specified - waits forever. If mutex is non-recursive and calling thread + owns it - error will be signaled (otherwise will deadlock). Return &t; if the thread got ownership of &mutex-r;, &nil; - on timeout. </simpara></listitem></varlistentry> <varlistentry id="mutex-unlock"><term><code>(&mutex-unlock; @@ -4920,13 +4910,17 @@ <varlistentry id="exemption-wait"><term><code>(&exemption-wait; &exemp-r; &mutex-r; &key-amp; &timeout-k;)</code></term> <listitem><simpara>Wait on &exemp-r; to become signaled. &mutex-r; should be - owned by the caller - if not error is signaled. The function releases + owned by the caller - if not - error is signaled. The function releases &mutex-r; ownership and waits on &exemp-r;. On return &mutex-r; is acquired - again. The function waits up to &timeout-k; &seconds; (which may be a - non-negative &real-t; or a list <literal role="data">(sec usec)</literal> - or a pair <literal role="data">(sec . usec)</literal>). If timeout is not + again. The function waits up to &timeout-k; &seconds;. If timeout is not specified - waits forever. Returns &t; if &exemp-r; was signaled, &nil; - - on timeout.</simpara></listitem></varlistentry> + on timeout.</simpara> + <note><simpara>With POSIX_THREADS it's possible to have spurious wake-ups. + See: <ulink url="http://opengroup.org/onlinepubs/007908799/xsh/pthread_cond_wait.html"> + pthread_cond_wait</ulink> + and <ulink url="http://en.wikipedia.org/wiki/Spurious_wakeup"> + Spurious wakeup</ulink></simpara></note> +</listitem></varlistentry> <varlistentry id="exemption-broadcast"><term><code>(&exemption-broadcast; &exemp-r;)</code></term> <listitem><simpara>Signal &exemp-r; in all thread waiting on it</simpara> ------------------------------ Message: 3 Date: Mon, 22 Jun 2009 02:02:20 +0000 From: Sam Steingold <sd...@us...> Subject: clisp/doc impext.xml,1.592,1.593 To: cli...@li... Message-ID: <E1M...@dd...> Update of /cvsroot/clisp/clisp/doc In directory ddv4jf1.ch3.sourceforge.com:/tmp/cvs-serv12021 Modified Files: impext.xml Log Message: formatting, links, clarifications, grammar Index: impext.xml =================================================================== RCS file: /cvsroot/clisp/clisp/doc/impext.xml,v retrieving revision 1.592 retrieving revision 1.593 diff -u -d -r1.592 -r1.593 --- impext.xml 21 Jun 2009 21:40:21 -0000 1.592 +++ impext.xml 22 Jun 2009 02:02:17 -0000 1.593 @@ -4686,8 +4686,7 @@ <section id="mt-intro"><title>Introduction</title> <para>&clisp; uses the OS threads. - Two flavors are supported: <emphasis>POSIX</emphasis> - and <emphasis>WIN32</emphasis>. Both are preemptive.</para> + Two flavors are supported: &posix; and &win32;. Both are preemptive.</para> <para>All functions and macros are exported from the package &mt-pac;. When this functionality if present, &features-my; contains the symbol <constant>:MT</constant> @@ -4717,12 +4716,12 @@ <section id="mt-symvalue"><title>Special Variable Values</title> <para>Special variables work in very similar/same way as in other - implementations.</para> + implementations.</para> <para>Every special variable has global value that can be shared across all -threads.</para> + threads.</para> <para>Bindings of special variables (via &let;/&let-star;/&multiple-value-bind;) - are local to thread i.e. every symbol has different value cell in each thread. - &symbol-value-thread; can be used to inspect/set these local thread bindings. + are local to thread i.e. every symbol has different value cell in each thread. + &symbol-value-thread; can be used to inspect/set these local thread bindings. </para> <para>Threads do not inherit dynamic bindings from the parent thread</para> @@ -4737,21 +4736,22 @@ ) (setq *global* 30))<lineannotation>&glob-var; value is modified again</lineannotation> (let ((*global* 2))<lineannotation>&thr-var; value is initialized</lineannotation> - (make-thread #'thread-1)) + (&make-thread; #'thread-1)) </programlisting></para> </section> -<section id="mt-package"><title>Packages</title><para> - PACKAGE objects have internal mutex and are locked by INTERN before adding a - symbol (if FIND-SYMBOL fails). All modifications of internal package data - are guarded by this mutex.</para> - <warning><para>Currently there is one exception: &use-package; is not protected and - thus not thread safe.</para></warning> - <warning><para>Symbol look-up within package currently is not guarded! This means - that in certain cases &find-symbol; may return &nil; even though the symbol - is accessible (this may happen when internal package hash tables are - re-hashed at the time &find-symbol; performs look-up).</para></warning> +<section id="mt-package"><title>Packages</title> +<para>&package-t; objects have an internal mutex and are locked by + &intern; before adding a symbol (if &find-symbol; fails). All + modifications of internal package data are guarded by this mutex.</para> +<warning><para>Currently there is one exception: &use-package; is not + protected and thus not thread safe.</para></warning> +<warning><para>Symbol look-up within package currently is not guarded! + This means that in certain cases &find-symbol; may return &nil; even + though the symbol is accessible (this may happen when internal package + hash tables are re-hashed at the time &find-symbol; performs look-up). +</para></warning> </section> <section id="mt-mutable"><title>Hash Tables, Sequences, and other @@ -4821,14 +4821,14 @@ <varlistentry id="thread-interrupt"><term><code>(&thread-interrupt; &thr; &func-r; &rest-amp; &args-r;)</code></term> <listitem><simpara>Interrupt normal execution flow in &thr; and ask it to - funcall &func-r; (with parameters). Thread cannot be interrupted at any - point - only at ones where GC can run - see <xref linkend="gc-mt"/>. - </simpara><simpara>Currently on WIN32 blocking I/O cannot be interrupted. The - interrupt will be handled after the call returns. - </simpara><warning><para> Thread may be interrupted inside - &unwind-protect;'s cleanup forms and on non-local exit from &func-r; - - they may not execute entirely. In order to prevent this - WITH-DEFERRED-INTERRUPTS is provided.</para></warning> + funcall &func-r; (with parameters). Thread cannot be interrupted at any + point - only at ones where GC can run, see <xref linkend="gc-mt"/>. + </simpara><simpara>Currently on &win32; blocking I/O cannot be interrupted. + The interrupt will be handled after the call returns.</simpara> + <warning><para>Thread may be interrupted inside &unwind-protect;'s + cleanup forms and on non-local exit from &func-r; - + they may not execute entirely. In order to prevent this + &with-deferred-interrupts; is provided.</para></warning> </listitem></varlistentry> <varlistentry id="thread-name"><term><code>(&thread-name; &thr;)</code></term> <listitem><simpara>Return the &name-r; of the &thr;. @@ -4837,8 +4837,8 @@ &thr;)</code></term> <listitem><simpara>Return &nil; if the thread has already terminated and &t; otherwise.</simpara> - <warning><para>By the time this function returns, &thr; may have - already terminated.</para></warning></listitem></varlistentry> + <warning><para>By the time this function returns &t;, &thr; may have + already terminated anyway.</para></warning></listitem></varlistentry> <varlistentry id="current-thread"><term><code>(¤t-thread;)</code></term> <listitem><simpara>Return the &thread; object encapsulating the caller. </simpara></listitem></varlistentry> @@ -4856,43 +4856,49 @@ </simpara></listitem></varlistentry> <varlistentry id="make-mutex"><term><code>(&make-mutex; &key-amp; &name-k; :RECURSIVE-P)</code></term> - <listitem><simpara>Create new &mutex; object - not owned by any thread. - &name-k; should be string describing the mutex (this really helps debugging - deadlocks). When :RECURSIVE-P is non-&nil; - recursive mutex is created i.e. - thread can acquire many times the mutex (and should release it for each - successful acquire of course). -</simpara></listitem></varlistentry> + <listitem><simpara>Create new &mutex; object - not locked by any thread. + &name-k; should be a &string-t; describing the mutex (this really helps + debugging deadlocks). When <constant>:RECURSIVE-P</constant> is + non-&nil;, a recursive mutex is created i.e. threads can acquire the + mutex many times (and should release it for each successful + acquisition of course).</simpara></listitem></varlistentry> <varlistentry id="mutex-lock"><term><code>(&mutex-lock; &mutex-r; &key-amp; &timeout-k;)</code></term> - <listitem><simpara>Acquire mutex. If mutex is owned by another thread - the - call blocks and waits up to &timeout-k; &seconds;. If timeout is not - specified - waits forever. If mutex is non-recursive and calling thread - owns it - error will be signaled (otherwise will deadlock). - Return &t; if the thread got ownership of &mutex-r;, &nil; - on timeout. + <listitem><simpara>Acquire the &mutex-r;. If &mutex-r; is locked by + another thread, the call blocks and waits up to &timeout-k; &seconds;. + If &timeout-k; is not specified, waits forever. If &mutex-r; is + non-recursive and the calling thread has already locked it, an &err-sig;. + If &mutex-r; is recursive, the call deadlocks. + FIXME: how to get out of the deadlock??? &thread-interrupt;?! + FIXME: this does not make sense. if such a call deadlocks, what use + are recursive mutexes?! + Return &t; on a successful locking of &mutex-r;, and &nil; on timeout. </simpara></listitem></varlistentry> <varlistentry id="mutex-unlock"><term><code>(&mutex-unlock; &mutex-r;)</code></term> - <listitem><simpara>Release &mutex-r; ownership. If the calling thread is not - owner of &mutex-r; - error is signaled. -</simpara></listitem></varlistentry> + <listitem><simpara>Release (unlock) &mutex-r;. If the calling thread is + not locking &mutex-r;, an &err-sig;.</simpara></listitem></varlistentry> <varlistentry id="mutex-owner"><term><code>(&mutex-owner; &mutex-r;)</code></term> - <listitem><simpara>Return &thread; that owns &mutex-r;, &nil; if none.</simpara> - <warning><para>By the time this function returns the &mutex-r; ownership may - have changed (unless the owner is not the ¤t-thread;). The function - is mostly useful for debugging deadlocks. -</para></warning></listitem></varlistentry> + <listitem><simpara>Return the &thread; that owns (locks) &mutex-r;, + or &nil; if &mutex-r; is not locked.</simpara> + <warning><para>By the time this function returns the &mutex-r; + ownership may have changed (unless the owner is not the + ¤t-thread;). The function is mostly useful for debugging + deadlocks.</para></warning></listitem></varlistentry> <varlistentry id="mutex-recursive-p"><term><code>(&mutex-recursive-p; &mutex-r;)</code></term> - <listitem><simpara>Return whether mutex is recursive</simpara></listitem></varlistentry> + <listitem><simpara>Return whether mutex is recursive. +</simpara></listitem></varlistentry> <varlistentry id="with-lock"><term><code>(&with-lock; (&mutex-r;) &body-amp; &body-r;)</code></term> - <listitem><simpara>Execute &body-r; with &mutex-r; owned. Upon exit &mutex-r; - ownership is released. Return the values of &body-r; evaluation</simpara> -</listitem></varlistentry> + <listitem><simpara>Execute &body-r; with &mutex-r; locked. + Upon exit &mutex-r; is released. Return whatever &body-r; returns. +</simpara></listitem></varlistentry> <varlistentry id="exemption"><term>&exemption;</term> - <listitem><simpara>The type of the object returned by &make-exemption;. These - are POSIX condition variables. + <listitem><simpara>The type of the object returned by &make-exemption;. + These correspond to the &posix; condition variables, + see <filename role="unix">pthread.h</filename>. </simpara></listitem></varlistentry> <varlistentry id="exemptionp"><term><code>(&exemptionp; &object-r;)</code></term> @@ -4900,31 +4906,32 @@ </simpara></listitem></varlistentry> <varlistentry id="make-exemption"><term><code>(&make-exemption; &key-amp; &name-k;)</code></term> - <listitem><simpara>Create new &exemption; object. &name-k; should be string - describing the exemption (this really helps debugging deadlocks)</simpara> -</listitem></varlistentry> + <listitem><simpara>Create a new &exemption; object. + &name-k; should be a &string-t; describing the exemption (this really + helps debugging deadlocks). +</simpara></listitem></varlistentry> <varlistentry id="exemption-signal"><term><code>(&exemption-signal; &exemp-r;)</code></term> - <listitem><simpara>Signal &exemp-r; object i.e. wake-up single thread blocked - on waiting for &exemp-r;</simpara></listitem></varlistentry> + <listitem><simpara>Signal &exemp-r; object, i.e. wake up the thread blocked + on waiting for &exemp-r;.</simpara></listitem></varlistentry> <varlistentry id="exemption-wait"><term><code>(&exemption-wait; &exemp-r; &mutex-r; &key-amp; &timeout-k;)</code></term> - <listitem><simpara>Wait on &exemp-r; to become signaled. &mutex-r; should be - owned by the caller - if not - error is signaled. The function releases - &mutex-r; ownership and waits on &exemp-r;. On return &mutex-r; is acquired - again. The function waits up to &timeout-k; &seconds;. If timeout is not - specified - waits forever. Returns &t; if &exemp-r; was signaled, &nil; - - on timeout.</simpara> - <note><simpara>With POSIX_THREADS it's possible to have spurious wake-ups. - See: <ulink url="http://opengroup.org/onlinepubs/007908799/xsh/pthread_cond_wait.html"> - pthread_cond_wait</ulink> - and <ulink url="http://en.wikipedia.org/wiki/Spurious_wakeup"> - Spurious wakeup</ulink></simpara></note> + <listitem><simpara>Wait for &exemp-r; to become signaled. + &mutex-r; should be locked by the caller; otherwise an &err-sig;. + The function releases the &mutex-r; and waits for &exemp-r;. + On return &mutex-r; is acquired again. + The function waits up to &timeout-k; &seconds;. + If timeout is not specified, waits forever. + Returns &t; if &exemp-r; was signaled, and &nil; - on timeout.</simpara> + <note><simpara>On &posix; it is possible to have spurious wake-ups. + See <function role="unix">pthread_cond_wait</function> + and <ulink url="http://en.wikipedia.org/wiki/Spurious_wakeup">Spurious + wakeup</ulink></simpara></note> </listitem></varlistentry> <varlistentry id="exemption-broadcast"><term><code>(&exemption-broadcast; &exemp-r;)</code></term> - <listitem><simpara>Signal &exemp-r; in all thread waiting on it</simpara> -</listitem></varlistentry> + <listitem><simpara>Signal &exemp-r; to all threads waiting for it. +</simpara></listitem></varlistentry> <varlistentry id="y-or-n-p-timeout"><term><code>(&y-or-n-p-timeout; seconds default &rest-amp; &args-r;)</code></term> <term><code>(&yes-or-no-p-timeout; seconds default &rest-amp; @@ -4932,14 +4939,13 @@ <listitem><simpara>FIXME</simpara></listitem></varlistentry> <varlistentry id="with-timeout"><term><code>(&with-timeout; (seconds &body-amp; timeout-forms) &body-amp; &body-r;)</code></term> - <listitem><simpara>Execute &body-r;. In case it does not finish for up to - &seconds; (which can be a non-negative &real-t; or a list - <literal role="data">(sec usec)</literal> or a pair <literal role="data"> - (sec . usec)</literal>) it is interrupted and timeout-forms are executed. - Return value(s) of last evaluated form.</simpara><warning><para> Since on - timeout current thread is interrupted special care may be needed for - ensuring proper cleanup in &body-r;. See &thread-interrupt; and - WITH-DEFERRED-INTERRUPTS</para></warning> + <listitem><simpara>Execute &body-r;. If it does not finish for up to + &seconds;, it is interrupted and <replaceable>timeout-forms</replaceable> + are executed. + Return the values of the last evaluated form.</simpara> + <warning><para>Since on timeout the current thread is interrupted, + special care may be needed for ensuring proper cleanup in &body-r;. + See &thread-interrupt; and &with-deferred-interrupts;.</para></warning> </listitem></varlistentry> <varlistentry id="symbol-value-thread"><term><code>(&setf; (&symbol-value-thread; &symbol-r; &thr;) &value-r;)</code></term> @@ -4949,7 +4955,7 @@ &glob-var; binding. Returns two values: the &symbol-r; binding and an indicator: &nil; if not bound in the &thr;, &t; if bound, and &symbol-t; &makunbound; if - the <emphasis>Per-Thread</emphasis> binding was removed with &makunbound;. + the &thr-var; binding was removed with &makunbound;. </simpara></listitem></varlistentry> <varlistentry id="default-special-bindings"> <term>&default-special-bindings;</term> @@ -4957,14 +4963,14 @@ argument of &make-thread;.</simpara></listitem></varlistentry> <varlistentry id="with-deferred-interrupts"><term> <code>(&with-deferred-interrupts; &body-amp; &body-r;)</code></term> - <listitem><simpara>Defer thread interrupts (NB: not thread preemption) while - &body-r; is executed. If there is interrupt while &body-r; is run - it is - queued and will be executed after &body-r; finishes.</simpara> - <warning><para> - Attention is required if waiting/blocking in &body-r; since there - is no way to interrupt it (in case of deadlock). The macro was added - to avoid partial &unwind-protect;'s cleanup forms evaluation in - case they are interrupted with non-local exit. + <listitem><simpara>Defer thread interrupts (but ¬-e; thread + preemption) while &body-r; is executed. If there is an interrupt + while &body-r; is run, it is queued and will be executed after + &body-r; finishes.</simpara> + <warning><para>Attention is required if waiting/blocking in &body-r; + since there is no way to interrupt it (in case of deadlock). + The macro was added to avoid partial &unwind-protect;'s cleanup + forms evaluation in case they are interrupted with a non-local exit. </para></warning></listitem></varlistentry> </variablelist></section> </section> ------------------------------ Message: 4 Date: Mon, 22 Jun 2009 02:54:33 +0000 From: Sam Steingold <sd...@us...> Subject: clisp/doc impext.xml,1.593,1.594 To: cli...@li... Message-ID: <E1M...@dd...> Update of /cvsroot/clisp/clisp/doc In directory ddv4jf1.ch3.sourceforge.com:/tmp/cvs-serv20390 Modified Files: impext.xml Log Message: mt-api: link to the appropriate POSIX function Index: impext.xml =================================================================== RCS file: /cvsroot/clisp/clisp/doc/impext.xml,v retrieving revision 1.593 retrieving revision 1.594 diff -u -d -r1.593 -r1.594 --- impext.xml 22 Jun 2009 02:02:17 -0000 1.593 +++ impext.xml 22 Jun 2009 02:54:30 -0000 1.594 @@ -4807,14 +4807,16 @@ used when &clisp; was started. If 0, the value will be the same as that of the calling thread. </simpara></listitem></varlistentry></variablelist> + <simpara>Cf. <function role="unix">pthread_create</function>.</simpara> </listitem></varlistentry> <varlistentry id="threadp"><term><code>(&threadp; &object-r;)</code></term> <listitem><simpara>Check whether the object is of type &thread;. </simpara></listitem></varlistentry> <varlistentry id="thread-yield"><term><code>(&thread-yield; &thr;)</code></term> <listitem><simpara>Relinquish the CPU. The &thr; is placed at the end - of the run queue and another thread is scheduled to run. -</simpara></listitem></varlistentry> + of the run queue and another thread is scheduled to run.</simpara> + <simpara>Cf. <function role="unix">sched_yield</function>.</simpara> +</listitem></varlistentry> <varlistentry id="thread-kill"><term><code>(&thread-kill; &thr;)</code></term> <listitem><simpara>Call &thread-interrupt; telling the &thr; to terminate. </simpara></listitem></varlistentry> @@ -4861,7 +4863,9 @@ debugging deadlocks). When <constant>:RECURSIVE-P</constant> is non-&nil;, a recursive mutex is created i.e. threads can acquire the mutex many times (and should release it for each successful - acquisition of course).</simpara></listitem></varlistentry> + acquisition of course).</simpara> + <simpara>Cf. <function role="unix">pthread_mutex_init</function>.</simpara> +</listitem></varlistentry> <varlistentry id="mutex-lock"><term><code>(&mutex-lock; &mutex-r; &key-amp; &timeout-k;)</code></term> <listitem><simpara>Acquire the &mutex-r;. If &mutex-r; is locked by @@ -4873,11 +4877,14 @@ FIXME: this does not make sense. if such a call deadlocks, what use are recursive mutexes?! Return &t; on a successful locking of &mutex-r;, and &nil; on timeout. +</simpara><simpara>Cf. <function role="unix">pthread_mutex_lock</function>. </simpara></listitem></varlistentry> <varlistentry id="mutex-unlock"><term><code>(&mutex-unlock; &mutex-r;)</code></term> <listitem><simpara>Release (unlock) &mutex-r;. If the calling thread is - not locking &mutex-r;, an &err-sig;.</simpara></listitem></varlistentry> + not locking &mutex-r;, an &err-sig;.</simpara> + <simpara>Cf. <function role="unix">pthread_mutex_unlock</function>.</simpara> +</listitem></varlistentry> <varlistentry id="mutex-owner"><term><code>(&mutex-owner; &mutex-r;)</code></term> <listitem><simpara>Return the &thread; that owns (locks) &mutex-r;, @@ -4908,12 +4915,15 @@ &key-amp; &name-k;)</code></term> <listitem><simpara>Create a new &exemption; object. &name-k; should be a &string-t; describing the exemption (this really - helps debugging deadlocks). -</simpara></listitem></varlistentry> + helps debugging deadlocks).</simpara> + <simpara>Cf. <function role="unix">pthread_cond_init</function>.</simpara> +</listitem></varlistentry> <varlistentry id="exemption-signal"><term><code>(&exemption-signal; &exemp-r;)</code></term> <listitem><simpara>Signal &exemp-r; object, i.e. wake up the thread blocked - on waiting for &exemp-r;.</simpara></listitem></varlistentry> + on waiting for &exemp-r;.</simpara> + <simpara>Cf. <function role="unix">pthread_cond_signal</function>.</simpara> +</listitem></varlistentry> <varlistentry id="exemption-wait"><term><code>(&exemption-wait; &exemp-r; &mutex-r; &key-amp; &timeout-k;)</code></term> <listitem><simpara>Wait for &exemp-r; to become signaled. @@ -4924,13 +4934,14 @@ If timeout is not specified, waits forever. Returns &t; if &exemp-r; was signaled, and &nil; - on timeout.</simpara> <note><simpara>On &posix; it is possible to have spurious wake-ups. - See <function role="unix">pthread_cond_wait</function> - and <ulink url="http://en.wikipedia.org/wiki/Spurious_wakeup">Spurious + See <ulink url="http://en.wikipedia.org/wiki/Spurious_wakeup">Spurious wakeup</ulink></simpara></note> + <simpara>Cf. <function role="unix">pthread_cond_wait</function>.</simpara> </listitem></varlistentry> <varlistentry id="exemption-broadcast"><term><code>(&exemption-broadcast; &exemp-r;)</code></term> - <listitem><simpara>Signal &exemp-r; to all threads waiting for it. + <listitem><simpara>Signal &exemp-r; to all threads waiting for it.</simpara> + <simpara>Cf. <function role="unix">pthread_cond_broadcast</function>. </simpara></listitem></varlistentry> <varlistentry id="y-or-n-p-timeout"><term><code>(&y-or-n-p-timeout; seconds default &rest-amp; &args-r;)</code></term> ------------------------------ Message: 5 Date: Mon, 22 Jun 2009 02:55:26 +0000 From: Sam Steingold <sd...@us...> Subject: clisp/doc cl-ent.xml,1.139,1.140 To: cli...@li... Message-ID: <E1M...@dd...> Update of /cvsroot/clisp/clisp/doc In directory ddv4jf1.ch3.sourceforge.com:/tmp/cvs-serv20469 Modified Files: cl-ent.xml Log Message: posix: add entity Index: cl-ent.xml =================================================================== RCS file: /cvsroot/clisp/clisp/doc/cl-ent.xml,v retrieving revision 1.139 retrieving revision 1.140 diff -u -d -r1.139 -r1.140 --- cl-ent.xml 18 Jun 2009 19:13:44 -0000 1.139 +++ cl-ent.xml 22 Jun 2009 02:55:24 -0000 1.140 @@ -163,6 +163,7 @@ <!ENTITY unicode32 '<ulink url="http://www.unicode.org">Unicode</ulink> <ulink url="http://www.unicode.org/unicode/reports/tr28/">3.2</ulink>'> <!ENTITY win32 '<ulink url="http://winehq.org/"><emphasis role="platform">Win32</emphasis></ulink>'> <!ENTITY lfs '<ulink url="http://www.unix.org/version2/whatsnew/lfs.html"><emphasis role="platform">LFS</emphasis></ulink>'> +<!ENTITY posix '<ulink url="http://www.opengroup.org/austin/papers/posix_faq.html"><emphasis role="platform">POSIX</emphasis></ulink>'> <!-- *** etc *** --> <!ENTITY http '<ulink url="http://www.w3.org/Protocols/"><command>HTTP</command></ulink>'> ------------------------------ ------------------------------------------------------------------------------ Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org ------------------------------ _______________________________________________ clisp-cvs mailing list cli...@li... https://lists.sourceforge.net/lists/listinfo/clisp-cvs End of clisp-cvs Digest, Vol 38, Issue 30 ***************************************** |