From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-24 14:01:27
--- In boost_at_y..., Kick Damien-DKICK1 <dkick1_at_e...> wrote:
> Wil Evers [Wil_Evers_at_d...] wrote:
> > Since I'm always looking for ways to do portable multi-threading
> > 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
> > and other implementation details.
> Having been loosely following various of the Boost.threads threads
> a lurker for a while (I'm always struggling to keep up with the
> 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
> 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
> that denominator can get awfully low. If a library is
> sufficiently crippled by standardization, no serious
> will use it; they'll just go out and get a third-party
> that works.
As others have pointed out, at one point in time it was felt you
couldn't standardize file access with out crippling something on some
platforms. I think this is the same thing here.
> I wonder how much of this holds true for Boost.threads,
> and how much inherent contradiction there is in the desire for
> "addressing [...] the more difficult C++/MT issues" and not "having
> deal too much with platform-specific APIs," in general? For
> I've read Bill Kempf write as responses to comments, "you're
> 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."
Yes, but I've tried hard to limit such arguments in these threads.
We must pay attention to existing practice (this means both POSIX and
Windows as well as other MT endeavors such as Java Threads), but we
must also be careful that our personal biases toward some library
that we're used to using doesn't adversely effect the design of a C++
solution. My comments about thinking too much about POSIX wasn't
meant to indicate I think POSIX is poorly designed (it's not) or
isn't a valid approach (it is), only that locking the thought process
into a POSIX way of thinking a) ignores important concepts from other
libraries and, more importantly b) places the design into a C style
solution, which I think is a mistake. The more we work out the
details the closer Boost.Threads comes to be very similar to a thin
POSIX wrapper (probably to be exptected since POSIX is the best
example of a standardized design), but I've tried to stear us away
from that in order to insure this doesn't cripple the design for the
two reasons given above.
> 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
> interfaces to system functionality as POSIX is for C. I would love
> have Pthreads++, for example. When I go looking at Boost.threads, I
> am evaluating it against this hypothetical Pthreads++. Anything
> Pthreads++ would provide that Boost.threads does not, I count as a
> "bug" against Boost.threads.
"Bug" is a bit harsh, but in general I fully agree with you as long
as you speak in terms of missing functionality. If there are things
you find still missing, please, speak up! Some things are only
missing because they simply haven't been implemented yet, but it's
also possible I've missed functionality, which would be a terrible
> 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.
Cancellation is coming, and probably very soon. It was always on the
radar, but for obvious reasons it wasn't something that was easy to
> 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?)
Comments in the discussion, no, though the next release of
Boost.Threads will contain Mac Carbon support so maybe this will
> but what about, for example,
> programmers working in an embedded environment in which there is no
> concept of threads/processes?
There will be no requirement for them to support threads. This is
obviously true in Boost.Threads, and my understanding is that this is
the thinking of the Committee members as well.
> 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.
To really get this stuff to work we *NEED* core language changes
(nearly entirely with regard to the abstract machine and not any
> > A few weeks ago, a posting by Beman Dawes to
> > 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?
I won't presume to speak for the members, but I *think* they realize
that Boost.Threads is still undergoing development. Though I
presented to the committee, and the reactions I received were
favorable, there's not been a formal submission of a complete
proposal yet. I understand your fears and concerns, but I hope I can
keep this from becoming panic. There's a long road to go yet, and
we've not even begun to pick things apart to the level we'll need to
for a formal submission. If you have specific concerns, bring them
up on this list, and I assure you they will be addressed before the
Committee has to go through the process of evaluating a formal
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk