Re: [boost] Report from Berlin C++ Standards Committee meeting

From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2006-04-10 16:26:32

  >> I think all desired modifications can be proposed in the current
>> Boost Thread rework effort and aren't too intrusive. For thread
>> launching I prefer Kevlin Henney's proposal approach. Has the
>> committee rejected this approach?
> 
> You are not alone.  The problem is that Kevlin is a very busy man, and
> has not yet produced a full working proposal.  Likewise, I am not aware
> of a freely available reference implementation, whereas there are at
> least 3 known separate implementations of the Boost threads interface.

There is a partial implementation (threader, joiner and lockable) I 
wrote some months ago:

http://boost-consulting.com/vault/index.php?&direction=0&order=&directory=Concurrent%20Programming

See thread_ex.2005-08-31.zip. It's constructed above Boost.Thread. I 
didn't know then Boost.Thread's had unlock() function so I had to make 
ugly things to access Boost.Thread's mutex private functions. But the 
thread launcher is implemented with Boost.Thread and shared_ptr.

> The approach has not been rejected, but is unlikely to make it in time
> for TR2.  Likewise, the thread library itself is most likely destined
> for TR2 rather than C++0x, although I believe the evolution group would
> prefer us to be more aggressive on this.

We can implement thread launching interface above Boost.Thread, as in 
the wrapper I wrote. Using that wrapper to launch threads and condensing 
6 mutex types into 2 it's possible for TR2. We can let read write mutex 
(or shared_mutex, if you prefer that name) for C++0x along with a 
message queue. I will look to Pete's paper to propose changes to Boost 
mailing list (including Howard Hinnant's lock reduction).

> TR2 is shaping up nicely as a library offering system-services though,
> with FileSystem accepted, and threads and networking strongly under
> consideration.  Beeman's approach to error reporting for
> system-specific errors could be broken out of FileSystem and become the
> underpinning mechanism shared across all TR2 system-level libraries.

I'm trying to follow also that error reporting system with 
Boost.Interprocess, and I must say that I find that approach good in 
general.

Regards,

Ion