RE: [boost] Boost.threads standardization wishlist

From: Kick Damien-DKICK1 (dkick1_at_[hidden])
Date: 2002-01-24 13:15:38

Wil Evers [Wil_Evers_at_[hidden]] wrote:

> Since I'm always looking for ways to do portable multi-threading in
> C++, I checked the library's documentation to see how some of the
> more difficult C++/MT issues had been addressed, only to find out
> that Boost.threads doesn't address them at all.  [...] In my
> opinion, a standard C++ multi-threading library should allow me to
> do that without having to deal too much with platform-specific APIs
> and other implementation details.

Having been loosely following various of the Boost.threads threads as
a lurker for a while (I'm always struggling to keep up with the volume
and generally failing) and having read the above snippet from Wil
Evers post, I was reminded of something I read in "C/C++ Users
Journal: 20 Years and Counting," in C/C++ Users Journal Vol. 19,
No. 11, Nov 2001.  Marc Briand wrote:

        A few well-meaning C++ experts have suggested that the
        Standard should include graphics and multithreading libraries.
        Frankly, I think that idea is misguided.  Standard libraries
        represent the lowest common denominator among platform
        differences that can't be abstracted away.  When it comes to
        something as platform-dependent as graphics or multithreading,
        that denominator can get awfully low.  If a library is
        sufficiently crippled by standardization, no serious developer
        will use it; they'll just go out and get a third-party library
        that works.

I wonder how much of this holds true for Boost.threads, specifically,
and how much inherent contradiction there is in the desire for
"addressing [...] the more difficult C++/MT issues" and not "having to
deal too much with platform-specific APIs," in general?  For example,
I've read Bill Kempf write as responses to comments, "you're thinking
too much about POSIX."
<http://groups.yahoo.com/group/boost/message/22840> I've gotten the
sense that there tends to be a far amount of disagreements that
amounts to a "on Windows, I have done this" and "with Pthreads, I
would have done the other."  Well, I am a developer who has a POSIX
bias; i.e. I don't know Windows and have never written a line on it.
What I really would love to have would be POSIX++, a standard for C++
interfaces to system functionality as POSIX is for C.  I would love to
have Pthreads++, for example.  When I go looking at Boost.threads, I
am evaluating it against this hypothetical Pthreads++.  Anything that
Pthreads++ would provide that Boost.threads does not, I count as a
"bug" against Boost.threads.  I'm not sure, but I think that tends to
be the gist of the complaints about the lack of support for
cancellation (or weak, or not-yet-implemented, etc.), for example.
And I'm sure that there are plenty of Windows developers who
similarly don't know POSIX and are comparing Boost.threads to
whatever they know from the Windows environment.  And not just to
limit this to UNIX and Windows (have there been any comments towards
any platform other than these two?) but what about, for example,
programmers working in an embedded environment in which there is no
concept of threads/processes?  Perhaps this is just picking nits, but
I would rather see a POSIX++ first and then perhaps an effort to
develop an inter-POSIX-Windows standard (would not want to watch the
process of trying to get any agreement between GNU/Linux and Windows
camps).  However, not as part of the C++ standard library.

> A few weeks ago, a posting by Beman Dawes to comp.lang.c++.moderated
> caught my attention.  The posting said that Boost.threads had been
> submitted to the Committee for their upcoming C++ Standard Library
> Technical Report, and that the initial response from the Committee
> had been favorable.

Do no members of the committee share Marc Briand's view?  Do no
members see Boost.threads, for example, as suffering from the lowest
common denominator syndrome?

--
Damien Kick