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?
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.
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).
bordeaux-threads-devel@common-lisp.net
-
Attila Lendvai -
Greg Pfeil