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

[Steve Holden]

If I remember correctly (when threading was invented in the mid-1980s)
threads were originally described as "lightweight processes". The
perceived advantage at the time was the ability to have multiple threads
of control with shared memory: this was much faster than the available
inter-process communication mechanisms. On a single-processor computer
synchronization was much less of a problem.

regards
 Steve


Guido van Rossum wrote:
> Yes, this is what threads were designed for. As an abstraction to have
> multiple "threads of control" on a *single* processor (in a single
> process). The whole multi-core business came decades later. (Classic
> multi-processors have something called threads too, but they, too,
> came later than the original single-core-single-CPU thread concept,
> and often threads on those systems have properties that don't match
> how threads work on modern multi-core CPUs.)
> 
> On Sat, Dec 13, 2008 at 5:32 AM, Michael Foord
> <fuzzyman at voidspace.org.uk> wrote:
>> Lennart Regebro wrote:
>>> On Fri, Dec 12, 2008 at 02:13, Sturla Molden <sturla at molden.no> wrote:
>>>
>>>> I genuinely think the use of threads should be discouraged. It leads to
>>>> code that are full of bugs and difficult to maintain - race conditions,
>>>> deadlocks, and livelocks are common pitfalls.
>>>>
>>> The use of threads for load balancing should be discouraged, yes. That
>>> is not what they are designed for. Threads are designed to allow
>>> blocking processes to go on in the background without blocking the
>>> main process. This, they are very useful for. Removing thread support
>>> would therefore be a very big mistake. It's needed, it has it's uses,
>>> just not the one *you* want.
>>>
>>>
>> That's an interesting assertion about what threads were designed for. Do you
>> have anything to back it up?
>>

-- 
Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC              http://www.holdenweb.com/