Re: [boost] [boost thread rework] New version uploaded to Boost Vault

From: Matt Hurd (matt.hurd_at_[hidden])
Date: 2005-08-31 20:53:16

>On 01/09/05, David Abrahams <dave_at_[hidden]> wrote:
> Ion Gaztañaga <igaztanaga_at_[hidden]> 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.

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?

matt.
matt_at_[hidden]