[cpp-threads] [Fwd: TR2 and C++0x heads up]

[Andrei Alexandrescu]

I am glad to see the discussion picking up. At the same time, it looks 
like we're timeboxed (see the email quoted below) and that we need to 
create a schedule for producing proposals for standardization.

This is our window of opportunity not only for the threading model, but 
also for the threading library. If we don't do anything about it, the 
one logical thing will happen---someone else will. In this case, it's 
about Boost.Threads which I strongly believe is an inferior design. In 
fact, here's what I wrote in a discussion on the standardization mailing 
list:

--------------------------------------------------------------------

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.

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.

--------------------------------------------------------------------

So I'd like us to start thinking about (1) overlapping work on the 
memory model and the library primitives, and (2) creating a schedule 
with milestones, deliverables, and tasks that would allow us to realize 
this effort.

I am particularly addressing this email to Kevlin. He has ideas on 
threading library primitives that are brilliant and play very well with 
C++'s strengths and modus vivendi. Also Alexander's atomic<> template 
would sure add value.

Thoughts?


Andrei

-------- Original Message --------
Subject: TR2 and C++0x heads up
Date: Fri, 22 Apr 2005 11:20:14 -0400
From: Beman Dawes <bdawes at acm.org>
Reply-To: boost at lists.boost.org
Newsgroups: gmane.comp.lib.boost.devel

The C++ standards committee's Library Working Group has proposed a schedule
for library changes and extensions:

     * October 2005: cutoff date for C++0x major library proposals
     * October 2006: cutoff date for library TR2 proposals
     * April 2007: cutoff date for C++0x library clean-up papers

The usual rule-of-thumb is that new library components go in TR2, while
changes to existing components go in C++0x. The LWG will consider
exceptions to the rule on a case-by-case basis.

The LWG is planning to issue a "Call for Proposals" with details, but in
the meantime Boost developers might want to start thinking about which
Boost libraries they want to propose to the LWG. Because most proposals go
through one or more revisions before being accepted, it helps a proposal's
chances if it reaches the committee as many meetings as possible before the
final cut-off.

So far there are plans to propose Boost.Threads, Boost.Filesystem, and
Boost.Signals. As well as proposals for some of the more major libraries, I
personally hope someone will do a sweep through Boost looking at some of
the smaller utilities and helpers for a possible "Small Additions"
proposal.

--Beman

_______________________________________________
Unsubscribe & other changes: 
http://lists.boost.org/mailman/listinfo.cgi/boost