Matt Hurd wrote:
On 01/09/05, David Abrahams <dave@boost-consulting.com> wrote: Ion Gaztañaga <igaztanaga@gmail.com> writes:
I don't want to be a buzz-kill and I know it's not glamorous, but I'm really concerned about the health of the existing Boost.Thread primitives. IIUC, none of these cool high-level components you're working on can act as full replacements for the existing stuff.
In particular, for example, the Boost.Thread documentation needs a lot of work. The code, apparently, needs a rewrite in order to get it to use the Boost license, but that's probably too much to hope for right now.
I'd really like to know that the existing library is being actively and conscientiously maintained before we move on to bigger and better things.
Perhaps not too much to ask for...
I tend to agree with David's sentiment. I'd be happy to start a simplification and restructure of the basic primitives. The code should be restructured into platform specific implementations, like boost has elsewhere (such as the atomic inc for shared_prt), as the current code I find a little tricky to read.
With such a restructure the various platforms could have different maintainers to eliminate a bit of the difficulty of trying to support such a cross platform library.
I could pull together a basic posix-based implementation which could be used on win32 with the posix32 lib as well, though a native win32 should happen as most people would find the posix32 layer unacceptable. Perhaps the current implementation can be refactored to do this, but starting from a clean slate so that the work can be licensed under the boost license might be best.
Level 0 - basic atomic ops, fencing, thread, mutex (normal, recursive, rw), condition - to be replaced and updated with the work happening elsewhere by Lea, Boehm etal. This should also replace the atomic ops used by shared_ptr over time. Should be in a style that suits generic programming via a consistent interface which is currently lacking.
A number of these dealing with sharing objects, such as mutexes, semaphores, signaling events, are useful not merely in the context of threading but also in other contexts, such as interprocess communication, fibers, memory mapping and/or sharing etc. with other uses on different OSs. Might these be better put in their own separate Boost library, and then be used by Boost threading and whatever other Boost libraries might need them without incurring the overhead of linking to the entire threading library ?