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, 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 -- http://mail.python.org/mailman/listinfo/python-list
