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

From: Edward Diener (eddielee_at_[hidden])
Date: 2005-09-02 07:46:26

Matt Hurd wrote:
>>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.

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 ?