Re: Review: Boost.Threads

From: williamkempf_at_[hidden]
Date: 2001-09-24 16:24:14

--- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> 
> ----- Original Message -----
> From: "Peter Dimov" <pdimov_at_m...>
> 
> <all of your good arguments snipped>
> 
> >
> > Another perspective: we have three categories of users:
> >
> > 1. Threading experts;
> > 2. Pthread programmers;
> > 3. Programmers with little or no thread experience.
> >
> > The problem we're trying to solve, AFAICS, is that the current 
design does
> > not target (3). The proposed solutions so far concentrate on 
renaming
> > functions. Does this help?
> >
> > Not much, I'd say. We need another, higher level, abstraction 
layer that
> is
> > specifically designed with (3) in mind. Let's leave the current 
low-level
> > design suitable for (1) and (2). Using standard POSIX names (and
> semantics)
> > is such a step.
> 
> Okay, I'm convinced. ;-)
> 
> But one last lingering drop of resistance remains... whatever else 
we do,
> wait() still feels wrong as a member function of condition.

I understand, but I think enough people have explained this to the 
point that I'm not going to change anything.  The operation truly is 
on the condition and not on the thread, as Beman pointed out in his 
excellent response, and changing the name isn't really an option for 
historical reasons.  Too much existing inertia in all of this.

As for changing the name... one name change request that's been made 
several times that I've ignored I'd like to address one last time.  
The notify_one() and notify_all() methods on condition are more 
traditionally known as signal() and broadcast() respectively.  I was 
persuaded to change them at one point, but I'm feeling like this was 
a mistake.  I'm leaning towards changing them but I'll need to do so 
in the next day or two, so one final chance to argue this one.

Bill Kempf