$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: Cronje, Schalk (Schalk_Cronje_at_[hidden])
Date: 2005-05-05 10:12:41
-----Original Message-----
From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]] On Behalf Of Andrei Alexandrescu
(See Website
>I think I'd be representing the opinion of the entire group by saying
>that a library-only approach is naive at best. See for example "Threads
>Cannot Be Implemented As A Library" by Hans Boehm at
>http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf, paper admitted
>at the prestigious conference PLDI 2005 (sign that others believe Hans
>actually makes sense). Actually I believe that any expert in threading
>would cringe at the thought that Boost.Threads made it in the C++
standard.
You definitely speak for me here. I would not like to see it go in as
part of C++0x.
>Speaking for myself about the quality of Boost.Threads' design itself,
I
>would add that it compares unfavorably (to use an euphemism) with many
>other threading library interface for C++ or other languages - actually
>all I know of, including unpublicized ad-hoc threading libraries
>developed in-house at various companies I've worked with.
I am much more in favour of a generic decoupled approach such as what
Kevlin Henney has suggested
(http://www.two-sdg.demon.co.uk/curbralan/papers/accu/MoreC++Threading.p
df). This approach lends itself to even more generic abstractions such
as asynchronous functions as presented at Accu2005.