[Chicago] desktop development

[Tal Liron]

Threading isn't always necessary, true. But not all processes can be 
easily split into tiny tasks that you can insert into the event loop. 
And any application which deals with outside libraries and resources is 
likely one of these.


It's true that spawning a separate process is cheap, but it's also true 
that you can't share memory with it. The overhead of serializing data 
between processes can be more than that of synchronizing thread access. 
Another problem (rare in desktop applications, but standard in server 
applications) is that you would might need a lot of concurrent tasks. If 
each task is a processes, it means you'll take up a lot of memory. I 
think spawning tasks should be avoided like the plague! It's the easy 
programming solution, but the wasteful resource solution.


It seems to me that it's exactly in dynamic languages like Python, where 
data hiding is frowned upon and all classes are open, you would want the 
same openness for inter-task communication. And yet, I get this 
anti-threading sentiment all the time in the Python community. Which is 
why CPython has a GIL, why threading tools are almost non-existent in 
the standard library, and why most Python platforms are such a 
problematic choice for server platforms. This is something that Python 
culture should embrace more, but I don't see it happening, as this 
sentiment seems ingrained at the very top.


-Tal



On 12/03/2010 09:02 PM, Bryan Oakley wrote:

> On Fri, Dec 3, 2010 at 7:50 PM, Tal Liron<tal.liron at threecrickets.com>  wrote:
>> Any GUI that needs to run "something" in the background would need an extra
>> thread, if you want to keep the app responsive and have a good user
>> experience (asynchronous notifications, progress bars, etc.)
> That's not necessarily true. All GUIs have an event loop that is
> typically 90%+ idle. All those idle cycles can be used to do
> processing. If you take the time to divide up your work into small
> chunks you can easily do that work when the main thread is otherwise
> idle. Progress bars and asynchronous I/O are perfect cases for that
> (except in performance critical operations, of course).
>
> It's also possible (and IMHO more desireable) to push this heavy
> lifting into a separate process. That to me is a better solution than
> threads because separate processes are less complex than multiple
> threads. And in this day and age (certainly not true a dozen years
> ago!) the overhead of spawning another process is negligible.
>
> Sometimes, yes, a second thread is useful. I don't dispute that
> sometimes they are necessary. I just don't agree they are always
> necessary. Obviously, YMMV. To me, multiple threads are like modal
> dialog boxes: they should be avoided like the plague, but sometimes
> they are the exact right tool for the job.
> _______________________________________________
> Chicago mailing list
> Chicago at python.org
> http://mail.python.org/mailman/listinfo/chicago