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

From: Rene Rivera (grafik666_at_[hidden])
Date: 2003-01-08 18:46:16

[2003-01-08] William E. Kempf wrote:

>
>> 
>> 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.

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 ;-)

>> 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.

-- grafik - Don't Assume Anything
-- rrivera_at_[hidden] - grafik_at_[hidden]
-- 102708583_at_icq