[Python-Dev] The endless GIL debate: why not remove thread support instead?

[Nick Coghlan]

Sturla Molden wrote:
> Last month there was a discussion on Python-Dev regarding removal of
> reference counting to remove the GIL. I hope you forgive me for continuing
> the debate.

Anything to do with removing the GIL/threads/whatever other core
language feature someone doesn't like really belongs on c.l.p. or
python-ideas rather than here. Ideas should be at least remotely
feasible before they're brought to python-dev.

That said, I'll bite anyway...

Treating threads as communicating sequential processes (via the Queue
module) actually makes them pretty easy to use correctly.

They are then extraordinarily handy for performing multiple non-GIL
bound tasks (such as IO operations or number crunching using an
extension module like numpy) in parallel.

For GIL bound tasks, switching from the threading module to the
multiprocessing module now allows the activity to scale to multiple CPUs.

Removing thread support merely because concurrent programming is hard
(no matter how you do it) would be... odd (to say the least).

Changing the underlying concurrency mechanism from threads to
subinterpreters to processes to whole computers doesn't make
understanding and coping with the concepts involved in concurrency any
easier (and in fact will often make them harder to handle by increasing
the communications latency).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------