Re: Boost.threads standardization wishlist

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 
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.

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, 
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."

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 
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.

"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 
thing.

>  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 
finalize.

> 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 
change.

> 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 
syntactical changes).
 
> > 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?

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 
submission.

Bill Kempf