|
Boost : |
From: Mathew Robertson (mathew.robertson_at_[hidden])
Date: 2005-03-07 18:48:37
> >>>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.
Forcibly kill threads is never going to be a safe thing to do in C++, as it doesn't (yet) provide the ability to automatically unlock resources (unless it is using RAII).
That said, I also have had a need to forcibly kill a thread - I agree that it is useful functionality - I just said that it was hard to do safely...
<snip>
> 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?
...and there inlies the real question... isn't a public forum a great thing !
Mathew
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk