[Python-Dev] Pythonic concurrency - cooperative MT

[Bruce Eckel]

> I was just saying that it can be useful to mix cooperative threading and
> preemptive threading in the same app, i.e. have different domains of
> cooperative threading which are preemptively scheduled by the OS. That
> has nothing to do with the GIL, I think (but I don't know much in Python
> internals).

This is one of the interesting questions I'd like to answer (but which
probably requires some kind of  mathematician to prove one way or
another): Does a "complete" concurrency solution require both a
preemptive task management system and a cooperative one?

OS Processes are generally quite limited in number (although I
understand that BeOS was designed to create tons of lightweight
processes, which changed that particular picture). In Java, you can
usually create several hundred threads before it craps out.
Simulations and games could easily have thousands or even hundreds of
thousands of independent simulation units. If there are limits to the
number of concurrency drivers (threads, etc.), then that would suggest
that at some point you have to move to a cooperative system. Which
would suggest that a "complete" concurrency solution might require
both.

That wouldn't be my ideal. My ideal would be a single solution that
would scale up to large numbers of concurrency units, and that
wouldn't require the programmer to remember to explicitly yield
control. Whether my ideal is possible is a question I'd like to
answer.

Bruce Eckel    http://www.BruceEckel.com   mailto:BruceEckel-Python3234 at mailblocks.com
Contains electronic books: "Thinking in Java 3e" & "Thinking in C++ 2e"
Web log: http://www.artima.com/weblogs/index.jsp?blogger=beckel
Subscribe to my newsletter:
http://www.mindview.net/Newsletter
My schedule can be found at:
http://www.mindview.net/Calendar