From attila.lendvai at gmail.com Mon Jun 4 21:56:04 2007 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Mon, 4 Jun 2007 23:56:04 +0200 Subject: [Bordeaux-threads-devel] send/receive message api Message-ID: 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 From sellout42 at mac.com Tue Jun 5 04:06:35 2007 From: sellout42 at mac.com (Greg Pfeil) Date: Mon, 4 Jun 2007 21:06:35 -0700 Subject: [Bordeaux-threads-devel] send/receive message api In-Reply-To: References: Message-ID: On 4 Jun 2007, at 14:56, Attila Lendvai wrote: > 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. This sounds cool, but I think is a level above what Bordeaux-threads is intended to supply. I'd like to keep B-t as much of a portability layer as possible. > another thing i'm missing and which is not strictly a primitive is a > read/write lock (even if it's a naiive implementation). This sounds more like it may fit into B-t proper. Do you have a patch for this, too, or is it more of a "please add"? I know there's one other function I have to add to the library, too (although I can't remember what it is off the top of my head). It's something used in cl-muproc. Need to follow up on that ... > 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? I think the message API could be its own library. I personally am a fan of many small libraries, especially when you have something like ASDF-Install to handle acquiring them. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From attila.lendvai at gmail.com Tue Jun 5 08:56:26 2007 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Tue, 5 Jun 2007 10:56:26 +0200 Subject: [Bordeaux-threads-devel] send/receive message api In-Reply-To: References: Message-ID: > > another thing i'm missing and which is not strictly a primitive is a > > read/write lock (even if it's a naiive implementation). > > This sounds more like it may fit into B-t proper. Do you have a patch > for this, too, or is it more of a "please add"? it's more of the "please add" kind... :) i'm not a threading expert, but i know enough that implementing a correct read/write lock is not trivial. but if the time comes that we need it and there's still no off-the-shelf solution, then i'll read up on locking and implement it myself. currently our read/write lock macros serialize the readers, too. > > 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? > > I think the message API could be its own library. I personally am a > fan of many small libraries, especially when you have something like > ASDF-Install to handle acquiring them. i would be too, but the current library handling situation on CL is far from ideal, to say the least. hmm, and how about adding a new system to the b-t.asd which could be optionally loaded after b-t was loaded? that way b-t itself won't get bigger, only it's repo. and users would get both functionality with the same amount of headache and can chose which one to load and which one to ignore. but for now i'll just add this code to UCW (i don't expect it to be more then two pages). -- attila From ths at networkno.de Mon Jun 25 12:29:58 2007 From: ths at networkno.de (Thiemo Seufer) Date: Mon, 25 Jun 2007 13:29:58 +0100 Subject: [Bordeaux-threads-devel] [PATCH] Mark more Lisp implementations as unsupported Message-ID: <20070625122958.GA32359@networkno.de> 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.")