> From: Rene Rivera <[EMAIL PROTECTED]>
> [2003-01-08] William E. Kempf wrote:
> >> From: Rene Rivera <[EMAIL PROTECTED]>
> >> [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
[EMAIL PROTECTED]
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
