[Chicago] desktop development
tal.liron at threecrickets.com
Sat Dec 4 08:41:36 CET 2010
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.
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
More information about the Chicago