[boost] Re: What I Hate About How We Abstract System Dependence

From: Robert Mathews (rmathews_at_[hidden])
Date: 2005-03-07 11:55:29

<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.