Thought of the day
dan at tombstonezero.net
Mon Jan 14 15:44:35 CET 2013
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.
It took me a moment to figure it out, but in the end I smiled and I
> 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, 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
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.
More information about the Python-list