[2003-01-08] William E. Kempf wrote:
>
>>
>> From: Rene Rivera <[EMAIL PROTECTED]>
>> Date: 2003/01/08 Wed PM 03:38:07 EST
>> To: Boost mailing list <[EMAIL PROTECTED]>
>> 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
-- [EMAIL PROTECTED] - [EMAIL PROTECTED]
-- 102708583@icq
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
