Matt Hurd <matt.hurd@gmail.com> writes:
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.
Please, whatever you can do! But please do a fresh rewrite. That doesn't mean you can't look at the old code; you just have to type new characters ;-)
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.
Makes sense.
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.
Agree.
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.
Level 1 - futures, threadables, message queues, etc, primitives along the direction of Henney's work.
Level 2 - Framework abstractions to architect single process, multi-process, multi-computer workflows. Needs boost::net / comms to reach its potential.
Any thoughts?
Not familiar enough with the library internals to comment. -- Dave Abrahams Boost Consulting www.boost-consulting.com