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

From: Beman Dawes (bdawes_at_[hidden])
Date: 2003-01-10 16:53:06

At 07:38 AM 1/10/2003, William E. Kempf wrote:

 >I'm not enough of an expert to say, but I know the issue isn't that
 >simple. Let's look just at the priority scheduling for a second.
 >
 >The single largest request I've had for an addition to Boost.Threads is 
to
 >add priority support.  It's absolutely essential for realtime 
programmers,
 >and they would (rightfully) reject any library that doesn't support it.
 >
 >Now let's imagine there's a POSIX OS that doesn't support this.  You want
 >to say that none of the Boost.Threads (or a C++ standard library) can be
 >used on their platform, just because they don't have support for priority 

 >scheduling?

No, what I'd rather happen is that the implementation provides the priority 
support. How it is implemented is the implementor's problem.

 >And even if there's no POSIX platform like this, thinking in terms of a 
C++
 >standard, what about the other platforms that aren't Windows or POSIX?
 >What about embedded platforms, for instance?

Some platforms are so limited they fall outside the standard's "hosted" 
category, and we don't have to worry about them.

Some platforms are fully featured, so again no worries.

What you are worrying about seems to me to be platforms which might 
possibly support threads-lite, but not a full Boost.Threads implementation. 
One solution is to just say no. Another is to require the implementor 
simulate the missing features. Implementors should make their own call on 
that, based on their understanding of their market.

There is some chance you might talk me into accepting two flavors of 
threading for the Standard - full threads and threads-lite in effect.
But picking and choosing between four or five optional thread features 
leaves me cold.

I'm reminded of the situation with I/O years ago. When standards were first 
proposed for machine independent I/O, people said "we'll never use that - 
it doesn't allow us to specify I/O channels, blocking factor, etc." Well, 
those people are still writing assembler language I guess but who cares? 
OTOH, implementors said it would be too hard to implement some of the 
standard features that were required. Their customers moved on. Nowadays 
everyone is happy with platforms that either do or don't support disk 
drives, and no one asks for standard half-support or standard support for 
special device features.

--Beman