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

[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

[Bordeaux-threads-devel] with-thread-name
by Attila Lendvai 30 Oct '07

30 Oct '07

hi! i've got a macro that i need for debugging code and i think it would be useful for b-t. it's called with-thread-name, that appends the given string to the thread's name and restores the old name in an unwind-protect. it's useful when you have 10 nodes with 25 threads each and need to debug stuff like sbcl hanging in CLOSE on a socket. if you like the idea i can move it into b-t and package up as a darcs patch. -- attila

2 1

[Bordeaux-threads-devel] [PATCH] Mark more Lisp implementations as unsupported
by Thiemo Seufer 25 Jun '07

25 Jun '07

Hello All, the appended patch stops bordeaux-threads from compiling successfully for Lisp implementations which have no threading support enabled. Thiemo --- bordeaux-threads/src/allegro-orig.lisp 2006-06-06 03:44:26.000000000 +0100 +++ bordeaux-threads/src/allegro.lisp 2007-06-24 12:13:40.000000000 +0100 @@ -75,3 +75,6 @@ (mp:process-kill thread)) ) ; end PROGN + +#-multiprocessing +(error "This implementation of ALLEGRO does not support threads.") --- bordeaux-threads/src/cmu-orig.lisp 2007-06-24 11:16:38.000000000 +0100 +++ bordeaux-threads/src/cmu.lisp 2007-06-24 12:13:58.000000000 +0100 @@ -84,3 +84,6 @@ (mp:destroy-process thread)) ) ; end PROGN + +#-mp +(error "This implementation of CMUCL does not support threads.") --- bordeaux-threads/src/sbcl-orig.lisp 2007-06-24 10:46:12.000000000 +0100 +++ bordeaux-threads/src/sbcl.lisp 2007-06-24 12:13:58.000000000 +0100 @@ -74,3 +74,6 @@ (sb-thread:terminate-thread thread)) ) ; end PROGN + +#-sb-thread +(error "This implementation of SBCL does not support threads.") --- bordeaux-threads/src/openmcl-orig.lisp 2006-06-06 03:44:26.000000000 +0100 +++ bordeaux-threads/src/openmcl.lisp 2007-06-24 12:14:14.000000000 +0100 @@ -83,4 +83,7 @@ (defmethod destroy-thread ((thread ccl:process)) (ccl:process-kill thread)) -) ; end PROGN \ No newline at end of file +) ; end PROGN + +#-openmcl-native-threads +(error "This implementation of OpenMCL does not support threads.")

1 0

[Bordeaux-threads-devel] send/receive message api
by Attila Lendvai 05 Jun '07

05 Jun '07

hi! i'm about to implement a simple send/receive message api based on condition variables and i wonder whether it fits the scope of bordeaux-threads... if you also think it does, then let me know and i'll send a patch. another thing i'm missing and which is not strictly a primitive is a read/write lock (even if it's a naiive implementation). i know that these features are implementable in terms of the current b-t api (i'm not sure about the read/write lock, though), but where else would we put them then a threading lib? -- attila

2 2

[Bordeaux-threads-devel] Allegro patch
by Henrik Hjelte 26 Sep '06

26 Sep '06

Here is a a little patch I needed to make UnCommonWeb work with Allegro 8.0. It's an implementation of make-recursive-lock and a small change to with-recursive-lock-held when no timeout is specified. /Henrik Hjelte

1 0

[Bordeaux-threads-devel] a patch to make it 'work' on non-threaded lisps
by Attila Lendvai 23 Aug '06

23 Aug '06

hi! as the title sais... small changes here and there to make it load on clisp and to provide a way for the apps to check for threads. -- - attila "- The truth is that I've been too considerate, and so became unintentionally cruel... - I understand. - No, you don't understand! We don't speak the same language!" (Ingmar Bergman - Smultronstället)

1 0

[Bordeaux-threads-devel] [PATCH] CMUCL bug-fixes
by Vladimir Sekissov 12 Jul '06

12 Jul '06

Good day, Here is a patch for CMUCL. Tested under CMUCL-19c. Best Regards, Vladimir Sekissov

1 0

[Bordeaux-threads-devel] Condition wait
by Hoan Ton-That 21 Jun '06

21 Jun '06

Greg, I'm writing CL-STM, and I was wondering if we could change `condition-wait' to take the lock as an optional argument? At the moment, I'm acquiring a dummy lock, and then using `condition-wait' on it. What do you think? Hoan

2 2