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

[Bordeaux-threads-devel] sbcl timeout fix
by Attila Lendvai 09 Sep '09

09 Sep '09

please find a fix attached. Tue Nov 18 20:36:34 CET 2008 attila.lendvai(a)gmail.com * fix sbcl timeout condition: export the sb-ext:timeout symbol from the bordeaux-threads package -- attila

1 1

Re: [Bordeaux-threads-devel] (initial-bindings *default-special-bindings*)
by Stelian Ionescu 31 Mar '09

31 Mar '09

On Fri, 2009-03-20 at 20:00 +0000, Martin Simmons wrote: > Sorry, there is confusion about what "bound" means here, since LET and SETQ > both make a symbol bound, but they behave differently with multithreading. I > think it is worth stating what we expect to happen. > > Let's use the term thread-specific binding for what is establish by LET (and > also PROGV and the new Bordeaux-threads default bindings). Each symbol also > has a global binding which is seen by all threads that have no thread-specific > binding. AFAIK, all implementations support this and using SETQ with a symbol > that has a thread-specific bindings in the current thread will not affect > other threads. > > I don't want the thread-specific bindings for the I/O variables of the current > thread to be inherited by a new thread. That's the capturing problem. > > Moreover, I think there should be no thread-specific bindings for the I/O > variables in the threading library, i.e. their global bindings should be > visible and changable. If an application wants to change the value, then it > should rebind it with LET, not assume that it can use SETQ. > > I hope that makes my position clearer. Ok, I yield to your arguments :). *default-special-bindings* now defaults to NIL and its previous value is in *standard-io-bindings* -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur.

2 1

[Bordeaux-threads-devel] Bug in binding-default-specials
by Gustavo 14 Mar '09

14 Mar '09

The remove-duplicates function should receive (:key #'car ) argument, since it is intended to remove the same variable being bound. Patch attached. By the way, I was thinking if it could be possible to bind some local variables (since not all implementations support closures). (defvar *closure-value-table* (make-hash-table :test #'eq :size 10)) (defmacro make-thread-with-closure ((&rest vars) function &rest make-thread-args) (let ((vars (mapcar #'(lambda (var) (if (atom var) (list var) var)) vars)) (table-code (gensym))) `(progn (setf (gethash ',table-code *closure-value-table*) (list ,@(mapcar #'second vars))) (make-thread (lambda () (destructuring-bind ,(mapcar #'car vars) (gethash ',table-code *closure-value-table*) (remhash ',table-code *closure-value-table*) (funcall ,function))) ,@make-thread-args)))) cl-user> (make-thread-with-closure ((a 1) (b 2)) (lambda () (+ a b))) #<sb-thread:thread "Anonymous" running {1005745721}> cl-user> * #<sb-thread:thread "Anonymous" finished values: 3 {1005745721}> cl-user> Maybe a lock is needed to access the hash-table since not all implementations support concurrent table access, but that is the general idea. Gustavo.

2 1