Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder2.hal-mli.net!de-l.enfer-du-nord.net!feeder1.enfer-du-nord.net!usenet-fr.net!nerim.net!novso.com!news2.euro.net!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Date: Mon, 14 Jan 2013 12:12:54 -0500
From: Dave Angel <d@davea.name>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: python-list@python.org
Subject: Re: Thought of the day
References: <50f3869d$0$29983$c3e8da3$5496439d@news.astraweb.com> <mailman.492.1358155623.2939.python-list@python.org> <nRUIs.51167$On7.15414@newsfe16.iad>
In-Reply-To: <nRUIs.51167$On7.15414@newsfe16.iad>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Precedence: list
Reply-To: d@davea.name
Newsgroups: comp.lang.python
Message-ID: <mailman.505.1358183593.2939.python-list@python.org>
Lines: 53
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:36799

On 01/14/2013 09:44 AM, Dan Sommers wrote:
> On Mon, 14 Jan 2013 00:31:59 -0500, Dave Angel wrote:
>
>> On 01/13/2013 11:16 PM, Steven D'Aprano wrote:
>>> A programmer had a problem, and thought Now he has "I know, I'll solve
>>> two it with threads!" problems.
>> ++10
> It took me a moment to figure it out, but in the end I smiled and I 
> agree:  +1.
>
>> I've been thinking about threads lately, and have come to the tentative
>> conclusion that they're a solution which has outlived its usefulness for
>> 99% of the use cases.  Much like the Windows 3.1 model of memory usage,
>> where all memory was shared, and apps promised not to step too hard on
>> each other.  Or the "640k is more memory than any application will ever
>> need" notion.
> With this, however, I don't agree.  If Python's GIL didn't interfere with 
> the concurrency of threads,

Better minds than mine have tried very hard to eliminate the GIL, so for
now I consider that a feature of Python.  If the GIL weren't needed for
the lowest levels of the interpreter, something else would be needed for
all the possible data structures that need atomic updates.  Hello
semaphores, mutexes, etc.  If threading were considered important in a
language, it'd have a way to declare an object sharable (default off),
and the low level code would go at full speed for any object not so
declared.  But the language would then provide guarantees for the
standard objects that are marked as sharable.  That's not current Python.

>  I can't think of a good reason to use 
> multiple processes instead, except to use a tool that runs outside the 
> Python virtual machine, or to provide more fault tolerance for long-
> running server-like applications.  We're all adults here, and if the 
> policy is to invoke the methods of objects as documented, then that 
> policy extends to stepping on (or not stepping on) the memory of other 
> threads, too.
>
> The APIs for threads and processes is pretty much the same, so I suppose 
> it doesn't matter much, either.  Use the right tool for the job.
>
> Dan

For other languages, I've done extensive work on projects with heavy
multithreading, and getting it right is extremely difficult.  Another
way of putting it is that any non-trivial project with multithreading is
probably buggy. 



-- 

DaveA