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

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

> From: Beman Dawes <bdawes_at_[hidden]>
> At 02:59 PM 1/9/2003, William E. Kempf wrote:
>  >> From: Beman Dawes <bdawes_at_[hidden]>
>  >> I'm not saying Boost.Threads should take exactly the same approach,
>  >> but I'd rather not see a lot of optional/conditional features to
>  >> support operating systems other than those two O/S families.
>  >
>  >Well, everything that's optional in what I proposed for Boost.Threads (so 
> 
>  >far) happens to also be optional on POSIX (and by using the same
>  >conditional compilation scheme).
> 
> So, don't provide Boost.Threads support for POSIX operating system flavors 
> which don't provide important optional POSIX features. Do any of the 
> important flavors of POSIX systems not provide these options?

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?  Does that actually make sense to you?

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?

> Remember, too, that you don't have to specify everything. You can leave it 
> up to the implementor to decide what to do on a crippled operating system. 
> I have a suspicion that is what the Standards committee may do with a lot 
> of thread related changes that we always assumed would go into the core 
> language execution model - don't mention the details, and just expect the 
> library implementor to make it all work correctly in the eyes of users. 
> Just as is done with the external effects of I/O operations now.

I'm not sure "the implementor" would be able to do anything about some of these issues if the OS doesn't provide support... and in some cases, even if he could, it would be prohibitive for him to do so (thinking of embedded systems).

> People will be afraid to use Boost.Threads if they think that even on a 
> fully-feature operating system some Boost.Threads features may not be 
> available, or the features may be available with one compiler but not 
> another.

I don't expect there to be compiler issues, only platform issues.  And again, this is EXACTLY the case in POSIX today... yet I don't see anyone scared to use it.
 

William E. Kempf
wekempf_at_[hidden]