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

From: William E. Kempf (wekempf_at_[hidden])
Date: 2003-01-10 17:07:01

> From: Beman Dawes <bdawes_at_[hidden]>
> 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.

>From a realtime programmers stand point, this isn't possible.  If the platform doesn't provide it there's no way for a library/compiler implementor to do this.

>  >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 can understand that, but my hands are somewhat tied by POSIX, whose standards bodies took the opposite stance on this issue.
 
> 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.

I'm not 100% sure the comparison is valid, because the domains are completely different.  But I appreciate and respect the view point.
 

William E. Kempf
wekempf_at_[hidden]