Re: Comments on the thread library

From: williamkempf_at_[hidden]
Date: 2001-03-26 10:06:04

--- In boost_at_y..., Lie-Quan Lee <llee1_at_l...> wrote:

I'm going to go back and respond to the post that originated all of 
this later, but this is the perfect opportunity for me to voice out 
on this subpoint.

> At Mon, 26 Mar 2001 08:41:54 -0500,
> David Abrahams wrote:
> > 
> > In the generative interfaces I have seen, the parameters name 
themselves.
> > Using named template parameters is overkill in this situation. 
What we want,
> > for ease-of-use, is simply an interface that allows the 
parameters to be
> > passed in any order. That is,
> > 
> >   mutex_generator<checked, nonrecursive>::type
> > 
> > is self-documenting, but should be equivalent to
> > 
> >   mutex_generator<nonrecursive, checked>::type
> > 
> > -Dave
> > 
> 
> As a matter of fact, there are quite a few features in the mutexes. 
To
> name a few, blocking policy, checked/unchecked,
> recursive/nonrecursive, acquisition
> scheduling(FIFO/priority/undefined), and owner priority and so
> on. 

This illustrates one of the big reasons why I'm not sure I care for a 
generative design for Boost.Threads.  Acquisition scheduling is 
nearly always going to be defined by the underlying implementation, 
so exposing an interface to specify this is misleading at best.  
You're not going to be able to specify this in a portable manner.  I 
designed the semantics of the Boost.Threads mutex types very 
carefully, taking factors like this into account.

The other reason I'm not sure that I care for a generative approach 
is because it leads to a much more complex design both to implement 
and to use.  If there's a mutex type that you feel is missing I'd 
prefer to see it implemented stand alone.  If it's a type that can be 
easily implemented portably, then it can even be included in 
Boost.Threads proper.
 
> Quickly, the number of template arguements could get larger than
> convenient to remember. Benefits of using named template arguement,
> including having default for all template arguements and making 
order
> of template arguement insignificant, will make users' life easy as 
you
> just suggest to do that in Boost.Graph. What do you think?

I think that the generative approach is going to do anything but make 
the user's life easy, regardless of whether or not named template 
parameters are used.  The "number of template arguments" getting 
overly large is just one reason why this is so.

Bill Kempf