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
> > not target (3). The proposed solutions so far concentrate on
> > functions. Does this help?
> > Not much, I'd say. We need another, higher level, abstraction
> > specifically designed with (3) in mind. Let's leave the current
> > design suitable for (1) and (2). Using standard POSIX names (and
> > is such a step.
> Okay, I'm convinced. ;-)
> But one last lingering drop of resistance remains... whatever else
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk