[EMAIL PROTECTED] wrote:
On May 16, 11:40 am, Roger Heathcote <[EMAIL PROTECTED]>
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
--
http://mail.python.org/mailman/listinfo/python-list
