[Python-Dev] Pythonic concurrency - cooperative MT

[Antoine Pitrou]

Le vendredi 30 septembre 2005 à 08:32 -0500, skip at pobox.com a écrit :
>     >> (C)  That scheduler is non-preemptive.  A single greedy generator can
>     >>      starve all the others.
> 
>     Antoine> Instead of looking at this as a problem, you could look at it
>     Antoine> as a feature.
> 
> Apple looked at it as a feature for years.  Not anymore.  <wink>

You are missing the context:
- at the OS level, it is not good to have cooperative MT because any
badly-written app (there are lots of ;-)) can cause lack of
responsiveness for the whole machine
- at the application level, cooperative MT can be good to enforce robust
semantics without disrupting other apps

The latter is what we are discussing AFAIK: a different concurrency
scheme inside a single application - not accross the whole OS or
desktop.

Actually, I think different concurrency schemes must be chosen and mixed
depending on the semantics. For example, when you have a networked GUI
app, it can be good to have the network in one preemptive thread (using
e.g. Twisted) and the GUI in another preemptive thread (using GTK,
wx...). This is because GUI and network have different latency
characteristics and requirements.
(of course, you can replace "preemptive thread" with "process" in the
above description)

So whatever innovatice concurrency scheme Python may come out, it should
still be mixable with more traditional concurrency schemes, because
required properties vary wildly even inside a single app.

Regards

Antoine.