<snip>
Here's another one of my favorite examples, in Boost.Threads ("Boost.Threads," <http://www.boost.org/doc/html/threads.html>). boost::thread lacks a method to forcefully terminate a thread, despite the fact that many threading systems have one.
So most people go with an implementation that does not provide forcible termination.
But not all. For example, we've got a large distributed system, many servers, many threads. During shutdown, we find it better behaviour to have a server kill an offending thread, complete the shutdown, and then report the problem somewhere as compared to the other behaviour of simply having the server hang until the operator has to intervene and kill it . Hence, I see a lot of value in even this particular example. <snip>
OK. I'm not concerned with this particular feature, but the fact that there will always be some feature that the system supports that a user may want that Boost.Threads will not implement. If its not this, then it might be thread priority, and if not that, then it might be setting a thread's processor affinity, or who knows what else.
My point is that the concrete Boost.Thread is not open for extension. If you want a feature it doesn't provide, you either have to modify the sources, or just write yourself an entirely new thread ibrary. This is should not be the way we do it in C++.
I have always thought that concrete implementations of portable libraries should supply users a way to get at the OS-specific data so they can use platform-specific facilities on them if neccessary.
You have to understand, the Boost.Threads specification was designed to become a standard, and as such it didn't include anything nonportable. That said, there's no reason we shouldn't expose the low-level thread IDs and document them in a special section on platform specifics.
========================================================== And then, if I wanted to write a "kill thread" method, I'd write a function that took the boost::thread, got the thread id, and called the appropriate system function? I could live with that - that way'd I'd at least be able to use the rest of the boost::thread libary in my application. One downside would that pretty soon there would be many many bootleg versions of the "kill thread" method and other platform-specific stuff for the platforms. Some of these versions would implement "kill thread" etc correctly, some would have subtle bugs, there would be different function prototypes, etc. I'd much prefer that if someelse has implemented the O/S specific features for threads on my platform, that way I'd benefit from the bug fixes and I'd be able to reuse the code. If the standard isn't a place where that type of code can be collected, where is the right place? Is there room for defining a mechanism for adding platform-specific extensions that contain concepts that may or may not be supported on all versions of the library? Thanks, Rob.