- bordeaux-threads-devel - mailman3.common-lisp.net

[Bordeaux-threads-devel] [PATCH] *default-special-bindings*
by Stephen Compall 28 Dec '08

28 Dec '08

Here is an implementation of *default-special-bindings*, with a test. I opted for thunks instead of forms to eval because eval is evil. They are called in the new thread; changing this is trivial by changing the binding-default-specials function used by all backends. However, I won't be using it for fluid-database (http://repo.or.cz/w/clsql/s11.git?a=shortlog;h=refs/heads/fluid-pools) because ht-fluids are easier to use and have a better guarantee of availability and finalization. -- I write stuff at http://failex.blogspot.com/ now. But the post formatter and themes are terrible for sharing code, the primary content, so it might go away sooner or later.

1 0

[Bordeaux-threads-devel] [PATCH] LIFT fix and hash-table-based fluids
by Stephen Compall 27 Dec '08

27 Dec '08

These implement fluids, or boxes for for thread-local values. They do not require threads to be made with bt:make-thread. The implementation assumes that the value answered by `current-thread' is EQL to the live values of past and future invocations within a particular thread. They also include a LIFT fix. -- I write stuff at http://failex.blogspot.com/ now. But the post formatter and themes are terrible for sharing code, the primary content, so it might go away sooner or later.

1 0

[Bordeaux-threads-devel] ECL recursive locks
by David Holz 15 Dec '08

15 Dec '08

Under ECL in at least Windows, the standard locks are always recursive-enabled, so the unimplemented *-recursive-lock functions should probably just point to the standard *-lock calls, or vice versa. _________________________________________________________________ Suspicious message? There’s an alert for that. http://windowslive.com/Explore/hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_broad2…

1 0

[Bordeaux-threads-devel] *default-special-bindings*
by Max Mikhanosha 14 Jul '08

14 Jul '08

Symbol *default-special-bindings* is exported and documented, but it does not appear to be implemented max@momoland:~/lisp-systems/bordeaux-threads_0.5.0> grep -i default-special **/* src/bordeaux-threads.lisp: #:*default-special-bindings* #:*supports-threads-p* src/bordeaux-threads.lisp:(defvar *default-special-bindings* '() Should not the make-thread function massage them and do (progv ...)? Regards, Max

1 0

[Bordeaux-threads-devel] BORDEAUX-THREADS:WITH-TIMEOUT, LIFT:WITH-TIMEOUT symbol conflict
by Marko Tapio Manninen 07 Jun '08

07 Jun '08

I thought this might interest, if it could be a cause of any problems in future: (sbcl.17 with threads on macbook 10.5.3) USE-PACKAGE #<PACKAGE "BORDEAUX-THREADS"> causes name-conflicts in #<PACKAGE "BORDEAUX-THREADS-TEST"> between the following symbols: BORDEAUX-THREADS:WITH-TIMEOUT, LIFT:WITH-TIMEOUT [Condition of type NAME-CONFLICT] See also: Common Lisp Hyperspec, 11.1.1.2.5 [:section] Restarts: 0: [RESOLVE-CONFLICT] Resolve conflict. 1: [TRY-RECOMPILING] Try recompiling bordeaux-threads-test 2: [RETRY] Retry performing #<ASDF:COMPILE-OP NIL {13197741}> on #<ASDF:CL-SOURCE-FILE "bordeaux-threads-test" {13197A09}>. 3: [ACCEPT] Continue, treating #<ASDF:COMPILE-OP NIL {13197741}> on #<ASDF:CL-SOURCE-FILE "bordeaux-threads-test" {13197A09}> as having been successful. 4: [ABORT] Return to SLIME's top level. 5: [TERMINATE-THREAD] Terminate this thread (#<THREAD "repl- thread" {1268F779}>) Backtrace: 0: (NAME-CONFLICT #<PACKAGE "BORDEAUX-THREADS-TEST"> USE-PACKAGE #<PACKAGE "BORDEAUX-THREADS">)[:EXTERNAL] 1: ((FLET SB-THREAD::WITH-RECURSIVE-SPINLOCK-THUNK)) 2: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-RECURSIVE- SPINLOCK]555)) 3: (SB-THREAD::CALL-WITH-RECURSIVE-SPINLOCK #<CLOSURE (FLET SB- THREAD::WITH-RECURSIVE-SPINLOCK-THUNK) {44FEE0D}> #S(SB- THREAD::SPINLOCK :NAME "Package Lock" :VALUE #<SB-THREAD:THREAD "repl- thread" {1268F779}>)) 4: (USE-PACKAGE (#<PACKAGE "COMMON-LISP"> #<PACKAGE "BORDEAUX- THREADS"> #<PACKAGE "LIFT">) #<PACKAGE "BORDEAUX-THREADS-TEST">) 5: (SB-IMPL::UPDATE-PACKAGE #<PACKAGE "BORDEAUX-THREADS-TEST"> NIL NIL NIL NIL (#<PACKAGE "COMMON-LISP"> #<PACKAGE "BORDEAUX-THREADS"> #<PACKAGE "LIFT">) NIL NIL NIL ("BORDEAUX-THREADS-TEST") NIL NIL) 6: (SB-INT:SIMPLE-EVAL-IN-LEXENV (SB-IMPL::%DEFPACKAGE "BORDEAUX- THREADS-TEST" (QUOTE NIL) (QUOTE NIL) (QUOTE NIL) (QUOTE NIL) ...) #<NULL-LEXENV>) 7: ((FLET SB-C::DEFAULT-PROCESSOR) (SB-IMPL::%DEFPACKAGE "BORDEAUX- THREADS-TEST" (QUOTE NIL) (QUOTE NIL) (QUOTE NIL) (QUOTE NIL) ...)) 8: (SB-C::PROCESS-TOPLEVEL-FORM (SB-IMPL::%DEFPACKAGE "BORDEAUX- THREADS-TEST" (QUOTE NIL) (QUOTE NIL) (QUOTE NIL) (QUOTE NIL) ...) ((EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE) (SB-IMPL:: %DEFPACKAGE "BORDEAUX-THREADS-TEST" # # # # ...)) SB-C::ORIGINAL- SOURCE-START 0 0) (:COMPILE-TOPLEVEL)) 9: (SB-C::PROCESS-TOPLEVEL-PROGN ((SB-IMPL::%DEFPACKAGE "BORDEAUX- THREADS-TEST" (QUOTE NIL) (QUOTE NIL) (QUOTE NIL) (QUOTE NIL) ...)) ((EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE) (SB-IMPL:: %DEFPACKAGE "BORDEAUX-THREADS-TEST" # # # # ...)) SB-C::ORIGINAL- SOURCE-START 0 0) (:COMPILE-TOPLEVEL)) 10: (SB-C::PROCESS-TOPLEVEL-FORM (EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD- TOPLEVEL :EXECUTE) (SB-IMPL::%DEFPACKAGE "BORDEAUX-THREADS- TEST" (QUOTE NIL) (QUOTE NIL) (QUOTE NIL) (QUOTE NIL) ...)) (SB- C::ORIGINAL-SOURCE-START 0 0) NIL) 11: ((FLET SB-C::DEFAULT-PROCESSOR) (DEFPACKAGE BORDEAUX-THREADS- TEST (:USE #:CL #:BORDEAUX-THREADS #:LIFT))) 12: (SB-C::PROCESS-TOPLEVEL-FORM (DEFPACKAGE BORDEAUX-THREADS-TEST (:USE #:CL #:BORDEAUX-THREADS #:LIFT)) (SB-C::ORIGINAL-SOURCE-START 0 0) NIL) 13: (SB-C::SUB-SUB-COMPILE-FILE #<SB-C::SOURCE-INFO >) 14: ((LAMBDA NIL)) 15: (SB-C::%WITH-COMPILATION-UNIT #<CLOSURE (LAMBDA NIL) {1299117D}>) [:EXTERNAL] 16: (SB-C::SUB-COMPILE-FILE #<SB-C::SOURCE-INFO >) 17: (COMPILE-FILE #P"/Users/mmstud/lisp/libs/bordeaux-threads/test/ bordeaux-threads-test.lisp")[:EXTERNAL] 18: ((SB-PCL::FAST-METHOD ASDF:PERFORM (ASDF:COMPILE-OP ASDF:CL- SOURCE-FILE)) #<unavailable argument> #<unavailable argument> #<ASDF:COMPILE-OP NIL {13197741}> #<ASDF:CL-SOURCE-FILE "bordeaux- threads-test" {13197A09}>) 19: ((LAMBDA (SB-PCL::.PV. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0. SB-PCL::.ARG1.)) #<unavailable argument> #<unavailable argument> #<ASDF:COMPILE-OP NIL {13197741}> #<ASDF:CL-SOURCE-FILE "bordeaux- threads-test" {13197A09}>) 20: ((SB-PCL::FAST-METHOD ASDF:PERFORM :AROUND (ASDF:COMPILE-OP ASDF:CL-SOURCE-FILE)) #<unavailable argument> #S(SB-PCL::FAST-METHOD- CALL :FUNCTION #<CLOSURE (LAMBDA #) {1297BA15}> :PV NIL :NEXT-METHOD- CALL NIL :ARG-INFO (2)) #<ASDF:COMPILE-OP NIL {13197741}> #<ASDF:CL- SOURCE-FILE "bordeaux-threads-test" {13197A09}>) 21: ((LAMBDA NIL)) 22: ((FLET SB-THREAD::WITH-RECURSIVE-LOCK-THUNK)) 23: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-RECURSIVE-LOCK]522)) 24: (SB-THREAD::CALL-WITH-RECURSIVE-LOCK #<CLOSURE (FLET SB- THREAD::WITH-RECURSIVE-LOCK-THUNK) {44FF6CD}> #S(SB-THREAD:MUTEX :NAME "big compiler lock" :%OWNER #<SB-THREAD:THREAD "repl- thread" {1268F779}> :LUTEX #<unknown pointer object, widetag=#x5E {1049A027}>)) 25: (SB-C::%WITH-COMPILATION-UNIT #<CLOSURE (LAMBDA NIL) {12A0C9DD}>) [:EXTERNAL] 26: (ASDF:OPERATE ASDF:LOAD-OP :BORDEAUX-THREADS-TEST)[:EXTERNAL] 27: (SB-INT:SIMPLE-EVAL-IN-LEXENV (ASDF:OOS (QUOTE ASDF:LOAD- OP) :BORDEAUX-THREADS-TEST) #<NULL-LEXENV>) 28: (SWANK::EVAL-REGION "(asdf:oos 'asdf:load-op :bordeaux-threads- test) ") 29: ((LAMBDA NIL))

2 1

[Bordeaux-threads-devel] Lispworks additions to Bordeaux - where do I submit?
by Matthew Lamari 02 Jun '08

02 Jun '08

I have a lispworks.lisp for bordeaux in which I've added a few entries to bring it more into line with sbcl and cmucl's capabilities Most notable is condition variable support. Lispworks doesn't appear to support the same conditionals per se (probably why it wasn't trivially added to bordeaux) but its Lispworks wait seems to poll some predicate at some interval - I emulated conditions out of these. The condition variable basically stores a hashtable (containing only unnotified waiters known to be waiting) and a t-list for supporting queue ordering. Notification notifies only a SINGLE ELEMENT, as the docs claimed was desirable. I've included checks for some plausible cases where a process could leave the wait for reasons other than receiving the notification; but to ensure that an eligible waiter receives the next notification when it arrives. Unwind-protection ensures that the registered waiter is removed from the data structure, and that any unseen notification is passed on to the next waiter. Please let me know if this sounds to be on the right track, and how/to whom I should submit the change.

2 1

[Bordeaux-threads-devel] Lispworks additions to Bordeaux - where to submit?
by Matt Lamari 01 Jun '08

01 Jun '08

I have a lispworks.lisp for bordeaux in which I've added a few entries to bring it more into line with sbcl and cmucl's capabilities Most notable is condition variable support. Lispworks doesn't appear to support the same conditionals per se (probably why it wasn't trivially added to bordeaux) but its Lispworks wait seems to poll some predicate at some interval - I emulated conditions out of these. The condition variable basically stores a hashtable (containing only unnotified waiters known to be waiting) and a t-list for supporting queue ordering. Notification notifies only a SINGLE ELEMENT, as the docs claimed was desirable. I've included checks for some plausible cases where a process could leave the wait for reasons other than receiving the notification; but to ensure that an eligible waiter receives the next notification when it arrives. Unwind-protection ensures that the registered waiter is removed from the data structure, and that any unseen notification is passed on to the next waiter. Please let me know if this sounds to be on the right track, and how/to whom I should submit the change.

1 0

[Bordeaux-threads-devel] THREAD-JOIN in ASDF Package
by Volkan YAZICI 09 Apr '08

09 Apr '08

Hi, Despite THREAD-JOIN is mentioned in the API documentation[1], it doesn't exist in the ASDF package[2] pointed by cliki. When do you plan to distribute it with the default ASDF package? Regards. [1] http://trac.common-lisp.net/bordeaux-threads/wiki/ApiDocumentation [2] http://common-lisp.net/project/bordeaux-threads/releases/bordeaux-threads_l…

1 0

[Bordeaux-threads-devel] Patch for the unsupported backend
by Stelian Ionescu 08 Dec '07

08 Dec '07

I've attached a patch that ensures that every bordeaux-threads form is a noop in the unsupported backend: all generic functions get a default method and macros expand to PROGN. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur.

1 0

[Bordeaux-threads-devel] deliver problem with LispWorks
by Jens Teich 17 Nov '07

17 Nov '07

Edi Weitz wrote: > On Sat, 17 Nov 2007 15:11:46 +0100, "Jens Teich" <info(a)jensteich.de> > wrote: > >> When I load my system without delivery I get these warnings at >> startup >> >>> ; Loading fasl file >>> d:\Projekte\Lisp\bordeaux-threads\src\bordeaux-threads.ofasl ; >>> Loading fasl file >>> d:\Projekte\Lisp\bordeaux-threads\src\lispworks.ofasl >>> Warning: (METHOD MAKE-THREAD (T)) being redefined in >>> d:\Projekte\Lisp\bordeaux- >>> threads\src\lispworks.lisp (previously in d:\Projekte\Lisp\bordeaux- >>> threads\src\bordeaux-threads.lisp). >>> Warning: (METHOD >>> MAKE-LOCK >>> NIL) being redefined in d:\Projekte\Lisp\bordeaux- >>> threads\src\lispworks.lisp (previously in d:\Projekte\Lisp\bordeaux- >>> threads\src\bordeaux-threads.lisp). >>> Warning: (DEFMACRO WITH-LOCK-HELD) being redefined in >>> d:\Projekte\Lisp\bordeaux- threads\src\lispworks.lisp (previously >>> in d:\Projekte\Lisp\bordeaux- threads\src\bordeaux-threads.lisp). >>> Warning: (METHOD >>> THREAD-YIELD >>> NIL) being redefined in d:\Projekte\Lisp\bordeaux- >>> threads\src\lispworks.lisp (previously in d:\Projekte\Lisp\bordeaux- >>> threads\src\bordeaux-threads.lisp). > > Sorry, I misread this message and thought you /only/ got these message > during delivery. I just checked and the reason you get the messages > seems to be in fact that the methods are defined twice. For example, > for MAKE-THREAD there's a DEFGENERIC in src/bordeaux-threads.lisp > which defines a method for (T) and in src/lispworks.lisp they again > define a method for (T). You should report that to the authors. > > (Or you shouldn't use bordeaux-threads at all. IIUC it's a > portability layer, so if you're only developing for LW, you don't need > it.) Regards Jens

1 0