From gugamilare at gmail.com Wed Mar 11 21:36:48 2009 From: gugamilare at gmail.com (Gustavo) Date: Wed, 11 Mar 2009 18:36:48 -0300 Subject: [Bordeaux-threads-devel] Bug in binding-default-specials Message-ID: <4be8713d0903111436r78092575x1aab056c2378bbf8@mail.gmail.com> 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))) , at make-thread-args)))) cl-user> (make-thread-with-closure ((a 1) (b 2)) (lambda () (+ a b))) # cl-user> * # 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: patch Type: application/octet-stream Size: 11785 bytes Desc: not available URL: From stelian.ionescu-zeus at poste.it Sat Mar 14 15:35:21 2009 From: stelian.ionescu-zeus at poste.it (Stelian Ionescu) Date: Sat, 14 Mar 2009 16:35:21 +0100 Subject: No subject In-Reply-To: <4be8713d0903111436r78092575x1aab056c2378bbf8@mail.gmail.com> References: <4be8713d0903111436r78092575x1aab056c2378bbf8@mail.gmail.com> Message-ID: <1237044921.3179.1.camel@localhost.localdomain> A non-text attachment was scrubbed... Name: not available Type: multipart/signed Size: 1 bytes Desc: not available URL: From stelian.ionescu-zeus at poste.it Mon Mar 30 13:46:08 2009 From: stelian.ionescu-zeus at poste.it (Stelian Ionescu) Date: Mon, 30 Mar 2009 15:46:08 +0200 Subject: [Bordeaux-threads-devel] (initial-bindings *default-special-bindings*) In-Reply-To: <200903202000.n2KK0xvd028613@higson.cam.lispworks.com> References: <200902262049.n1QKn7h7015611@higson.cam.lispworks.com> <1237046375.3179.5.camel@localhost.localdomain> <200903202000.n2KK0xvd028613@higson.cam.lispworks.com> Message-ID: <1238420768.3148.20.camel@localhost.localdomain> 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From martin at lispworks.com Tue Mar 31 19:11:03 2009 From: martin at lispworks.com (Martin Simmons) Date: Tue, 31 Mar 2009 20:11:03 +0100 Subject: [Bordeaux-threads-devel] (initial-bindings *default-special-bindings*) In-Reply-To: <1238420768.3148.20.camel@localhost.localdomain> (message from Stelian Ionescu on Mon, 30 Mar 2009 15:46:08 +0200) References: <200902262049.n1QKn7h7015611@higson.cam.lispworks.com> <1237046375.3179.5.camel@localhost.localdomain> <200903202000.n2KK0xvd028613@higson.cam.lispworks.com> <1238420768.3148.20.camel@localhost.localdomain> Message-ID: <200903311911.n2VJB3uG031605@higson.cam.lispworks.com> >>>>> On Mon, 30 Mar 2009 15:46:08 +0200, Stelian Ionescu said: > > 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* Great, thanks! -- Martin Simmons LispWorks Ltd http://www.lispworks.com/