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

From: William E. Kempf (wekempf_at_[hidden])
Date: 2003-01-09 06:43:48

> From: Rene Rivera <grafik666_at_[hidden]>
> [2003-01-08] William E. Kempf wrote:
> >> From: Rene Rivera <grafik666_at_[hidden]>
> >> [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.
> 
> Yes, I can see how the exception approach is not ideal, not just for the
> library but also for the user.
> 
> But as a user I would expect something other than an internal
> "BOOST_THREAD_ATTRIBUTES_STACKSIZE" to tell me that setting the stacksize is
> supported in the platform. At minimum I would expect a standard symbol, PP
> or otherwise, that tells me if I can use that feature. I would much rather
> see something like this... instead of a set of PP symbols:
> 
> struct thread_traits
> {
> #if defined(BOOST_THREAD_ATTRIBUTES_STACKSIZE)
>     typedef attributes_stacksize yes_type;
>     BOOST_STATIC_CONSTANT(bool, supports_attributes_stacksize = true);
> #else
>     typedef attributes_stacksize no_type;
>     BOOST_STATIC_CONSTANT(bool, supports_attributes_stacksize = false);
> #endif
> #if defined(BOOST_THREAD_ATTRIBUTES_STACKADDR)
>     typedef attributes_stackaddress yes_type;
>     BOOST_STATIC_CONSTANT(bool, supports_attributes_stackaddress = true);
> #else
>     typedef attributes_stackaddress no_type;
>     BOOST_STATIC_CONSTANT(bool, supports_attributes_stackaddress = false);
> #endif
> #if defined(BOOST_THREAD_PRIORITY_SCHEDULING)
>     typedef priority_scheduling yes_type;
>     BOOST_STATIC_CONSTANT(bool, supports_priority_scheduling = true);
> #else
>     typedef priority_scheduling no_type;
>     BOOST_STATIC_CONSTANT(bool, supports_priority_scheduling = false);
> #endif
> };
> 
> ... or something like that ;-)

I have no problems with that, necessarily, but how would you use this?  What benefits does it provide?  Would this be in addition to the _documented_ PP symbols?
 
> >> 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.
> 
> The one place I would like to have such a thing it would have to be id().
> 
> I have one, very overused, place in my code where I have to iterate on a
> list of objects, which have thread pointers to find the object given the
> current thread. It would somewhat cleaner and easier to understand if I
> could have a std::map<thread::ID,object*> instead.

That doesn't necessarily speak for an ID type in addition to boost::thread.  It only adds another requirement that could be met by boost::thread itself.  Either an operator<(), knowing that the ordering is arbitrary, or follow the same route as std::type_info and include a before().  Thoughts?
 

William E. Kempf
wekempf_at_[hidden]