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 | ncogh...@gmail.com | Brisbane, Australia --------------------------------------------------------------- _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
