> From: Beman Dawes <[EMAIL PROTECTED]> > 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 [EMAIL PROTECTED] _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
