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

[Beman Dawes]

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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost