Re: Re: [boost] Next revision of boost::thread

From: William E. Kempf (wekempf_at_[hidden])
Date: 2003-01-08 17:17:46

> 
> From: Rene Rivera <grafik666_at_[hidden]>
> Date: 2003/01/08 Wed PM 03:38:07 EST
> To: Boost mailing list <boost_at_[hidden]>
> Subject: Re: [boost] Next revision of boost::thread
> 
> [2003-01-08] William E. Kempf wrote:
> 
> >I'd appreciate comments on the above design.  Specifically I have these
> questions:
> >
> >
> >* Are there concerns about using conditional compilation and optional
> portions of the 
> >library, as POSIX does?  I believe this is the only way Boost.Threads and
> the C++ 
> >standard will be able to provide "portable" threading libraries that don't
> restrict 
> >implementation to a least common denominator approach.
> 
> I rather dislike the conditional compilation solution. It makes it rather
> harder to write portable code as it makes for doing conditional PP code
> outside of the library. Would it not be preferable to throw some form of
> "unimplemented"/"unsupported" exception? Another option would be a discovery
> interface to find out what's supported in the platform. Such a discovery
> interface could be used with MPL to get the equivalent of PP.

Note that we do throw exceptions in many cases where things aren't supported.  However, if a large category of functionality is not available, such as scheduling, there's reasons to prefer conditional compilation.  First, you can get rid of unecessary code.  Second, you know from attempts to compile whether or not code can actually be ported to a given platform.  IOW, the exception approach is only useful when you can compensate for the lack of a feature at run time.

> >* Should I not nest the thread::attributes class and instead have a 
> >boost::thread_attributes class?
> 
> I rather like it, I do that in much of my own code :-)
> 
> >Beyond this, I'd appreciate any other feedback as well.
> 
> Was there ever any consideration/discussion on exposing some form of thread
> ID? (appart from the implicit ID in operator==)

Yes... but I'm still trying to determine the requirements for that.  If the only usage for an ID is for comparison, and for diagnostic messages, then all that's missing in the current proposed design is an operator<<(ostream).  Otherwise, what's missing is an id() method and an ID type.
 

William E. Kempf
wekempf_at_[hidden]