Thread killing - I know I know!

[Roger Heathcote]

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.

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.

Roger Heathcote - technicalbloke.com