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

[Bordeaux-threads-devel] Clarifying some behavior in the documentation
by Vladimir Sedach 01 Dec '10

01 Dec '10

Hello, I've encountered two cases that affect behavior of code but aren't clarified in the documentation: 1. At least one implementation (SBCL) requires that the lock on which condition-wait is called is to be held by the thread that calls condition-notify on the corresponding CV. This should be mentioned in the documentation as a requirement. 2. It is undefined what happens when release-lock is called inside a with-lock-held on the same lock. SBCL and Clozure appear to handle this "properly," although I think the documented behavior should be the same as with regular release-lock ("It is an error to call this unless the lock has previously been acquired (and not released) by the same thread," that is, it should be an error to call release-lock inside a with-lock-held). Thank you, Vladimir

2 3

[Bordeaux-threads-devel] Bordeaux-Threads release 0.8.0
by Stelian Ionescu 02 Oct '10

02 Oct '10

There's a new release of Bordeaux-Threads. Noteworthy changes since 0.7.0: * Various bug fixes for MCL, Lispworks 5&6 and Clisp * Updates for ABCL and ECL * Added type BT:THREAD * Added function BT:START-MULTIPROCESSING * BT:INTERRUPT-THREAD now takes &REST args * Switched test suite to FiveAM -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib

1 0

[Bordeaux-threads-devel] *default-special-bindings* docstring in 0-8-8-dev
by james anderson 04 Sep '10

04 Sep '10

re: (defvar *default-special-bindings* nil "This variable holds an alist associating special variable symbols to forms to evaluate. Special variables named in this list will be locally bound in the new thread before it begins executing user code. This variable may be rebound around calls to MAKE-THREAD to add/alter default bindings. The effect of mutating this list is undefined, but earlier forms take precedence over later forms for the same symbol, so defaults may be overridden by consing to the head of the list.") at least for sbcl and clozure, one needs to append to the list. does the spec say something else somewhere? * (progv '(a s a) '(1 2 3) a) ; in: LAMBDA NIL ; (PROGV '(A S A) '(1 2 3) A) ; --> LET UNWIND-PROTECT FLET BLOCK MULTIPLE-VALUE-BIND MULTIPLE- VALUE-CALL ; --> BLOCK SB-C::%WITHIN-CLEANUP RETURN-FROM ; ==> ; (PROGN ; (LABELS ((#:UNBIND1 (SB-C::VARS) ; (DECLARE #) ; (LET # ; #)) ; (#:BIND0 (SB-C::VARS SB-C::VALS) ; (DECLARE #) ; (COND # # #))) ; (#:BIND0 '(A S A) '(1 2 3))) ; NIL ; A) ; ; caught WARNING: ; undefined variable: A ; ; compilation unit finished ; Undefined variable: ; A ; caught 1 WARNING condition 3 *

2 1

[Bordeaux-threads-devel] ECL implementation update
by Kamil Shakirov 23 Aug '10

23 Aug '10

Hi List, The attached patch adds support for condition variables and recursive locks supported by ECL implementation. All test cases now pass with ECL 10.7.1. -- wbr.

2 1

[Bordeaux-threads-devel] Is there a multi-implementation way to get a timeout on condition-notify?
by Matt Lamari 18 Aug '10

18 Aug '10

On lispworks (6) there's condition-notify-with-timeout. On SBCL - not sure - there's a with-timeout that can make a form throw; but a little birdie told me that it's not supported on all platforms. Any good ideas? I've toyed with ideas for emulating it; but they tend to fall down under scrutiny.

1 0

[Bordeaux-threads-devel] [BUG-FIX] Error: Symbol "CONDITION-SIGNAL" not found at all in the MP package.
by Ryan Hope 18 Aug '10

18 Aug '10

I get this error "Error: Symbol "CONDITION-SIGNAL" not found at all in the MP package." using bordeaux-threads from git on Lispworks6. Below is a fix... diff --git a/src/impl-lispworks.lisp b/src/impl-lispworks.lisp index 8c88b30..949e7ff 100644 --- a/src/impl-lispworks.lisp +++ b/src/impl-lispworks.lisp @@ -78,7 +78,7 @@ Distributed under the MIT license (see LICENSE file) #+(or lispworks6) (defun condition-notify (condition-variable) - (mp:condition-signal condition-variable)) + (mp:condition-variable-signal condition-variable)) (defun thread-yield () (mp:process-allow-scheduling)) -- Ryan Hope, M.S. CogWorks Lab Department of Cognitive Science Rensselaer Polytechnic Institute

2 1

[Bordeaux-threads-devel] Docs link dead.
by Robin Lee Powell 11 Jul '10

11 Jul '10

The API documentation link on http://common-lisp.net/project/bordeaux-threads/ is dead, and I can't find a replacement. -Robin -- http://singinst.org/ : Our last, best hope for a fantastic future. Lojban (http://www.lojban.org/) The language in which "this parrot is dead" is "ti poi spitaki cu morsi", but "this sentence is false" is "na nei". My personal page: http://www.digitalkingdom.org/rlp/

2 1

[Bordeaux-threads-devel] Source repository switch to git
by Stelian Ionescu 11 May '10

11 May '10

I've wanted for some time do get rid of darcs, and this is it: the main repository is now http://gitorious.org/bordeaux-threads/bordeaux-threads with a backup at http://common-lisp.net/gitweb?p=projects/bordeaux-threads/bordeaux-threads.… I'll eliminate the darcs repository in a week -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib

2 2

[Bordeaux-threads-devel] license verification for inclusion in de.setf.amqp
by james anderson 15 Feb '10

15 Feb '10

good morning; i have released a library, de.setf.amqp[1], which incorporates work of yours. the combined license is the gnu affero. please see the readme[2] for more information. this is to verify the contact information for your library's license. yours is the last respective contact. in some cases, there was none and i have substituted a mailing list as an immediate place-holder, even though, as subscription-only lists, it is not well suited to this purpose. please advise me, should an alternative contact be available. [1] : http://github.com/lisp/de.setf.amqp [2] : http://github.com/lisp/de.setf.amqp/blob/master/README.md

1 0

[Bordeaux-threads-devel] changes for mcl@5.2 (3)
by james anderson 14 Feb '10

14 Feb '10

2 1