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).