From: David Abrahams (dave_at_[hidden])
Date: 2005-03-07 08:56:28
"Aaron W. LaFramboise" <aaronrabiddog51_at_[hidden]> writes:
> Mathew Robertson wrote:
>> I'd argue that we know exactly - no more, no less -> either the
>> operating system supports a capability, or it doesn't. The only
>> real question is, 'when do we detect the capabilities,
>> at build time? at run time?'
> I think we need more granularity than this. One important
> counterexample is the case when a capability may be enabled while the
> operating system is running. For example, a driver may be loaded that
> presents a high-quality random number source.
>>>Hereâs another one of my favorite examples, in Boost.Threads
>>>boost::thread lacks a method to forcefully terminate a thread, despite
>>>the fact that many threading systems have one.
>> So most people go with an implementation that does not provide forcible termination.
> OK. I'm not concerned with this particular feature, but the fact that
> there will always be some feature that the system supports that a user
> may want that Boost.Threads will not implement. If its not this, then
> it might be thread priority, and if not that, then it might be setting a
> thread's processor affinity, or who knows what else.
> My point is that the concrete Boost.Thread is not open for extension.
> If you want a feature it doesn't provide, you either have to modify the
> sources, or just write yourself an entirely new thread ibrary. This is
> should not be the way we do it in C++.
I have always thought that concrete implementations of portable
libraries should supply users a way to get at the OS-specific data so
they can use platform-specific facilities on them if neccessary.
You have to understand, the Boost.Threads specification was designed
to become a standard, and as such it didn't include anything
nonportable. That said, there's no reason we shouldn't expose the
low-level thread IDs and document them in a special section on
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk