Thread killing - I know I know!

[Chris Mellon]

On Mon, May 19, 2008 at 11:36 AM, Roger Heathcote
<usenet at technicalbloke.com> wrote:
> sjdevnull at yahoo.com wrote:
>>
>> On May 16, 11:40 am, Roger Heathcote <use... at technicalbloke.com>
>> wrote:<snip>
>>>
>>> Despite many peoples insistence that allowing for the arbitrary killing
>>> of threads is a cardinal sin and although I have no particular threading
>>> problem to crack right now I remain interest in the taboo that is thread
>>> killing. The real world and it's data are messy and imperfect and I can
>
> <snip>
>>
>> In general, use processes when you can and threads only when you
>> must.  OS designers spent a lot of energy implementing protected
>> memory, no sense throwing out a fair chunk of that hard work unless
>> you actually need to.
>
> Fair point, but for sub processes that need to be in close contact with the
> original app, or very small functions that you'd like 100s or 1000s of it
> seems like a kludge having to spawn whole new processes build in socket
> communications and kill via explicit OS calls. I can't see that approach
> scaling particularly well but I guess there's no choice.
>

It's not a kludge - the whole reason why killing a thread is undefined
and a "cardinal sin" is because it's in your own address space and you
can't guarantee anything about how it left things when you killed it.
You simply can't have it both ways. If you want to be able to safely
and sanely kill an uncooperative thread (*especially* third party code
you don't control) you have to isolate it from your address space, and
this means a process. This is a fundamental problem with the entire
idea of shared-state concurrency. For the record, you can't use 1000s
of threads either - if you really need 1000s of concurrent things
running you need to re-think your concurrency model and possibly your
choice of languages and environment.

The messiness of the real world is *why* you should use processes, not
a reason to avoid them.

> Does anyone think it likely that the threading module (and threading in
> general) will be improved and augmented with features like timeouts and
> arbitrary threadicide in the next year or two?  Seems there's little scope
> for tapping the power of the current generation of multiple cores with the
> current pythons, tho I appreciate breakneck speed has never been a design
> objective it looks like multicore is set to be the next generation PC
> architecture.
>

They absolutely should not be. Adding an API which can't work in the
general case and is dangerous even when it can work does not do anyone
any favors.

> Roger Heathcote - technicalbloke.com
> --
> http://mail.python.org/mailman/listinfo/python-list
>