Python threading (was: Re: global interpreter lock not working as it should)

Martin v. Löwis loewis at
Fri Aug 9 04:18:45 EDT 2002

DIG <dig.list at> writes:

> (By the way, your assumption about the increase of thread
> performance in [1] is right for an ideal world. In the real world,
> you should precise WHAT is an overall performance for you in YOUR
> case, because (in my opinion) it is rare enough, when performance
> can be defined as the number of instruction per time unit.

Most people do associate "performance" with the time that a certain
task needs to complete on the computer - the smaller the time, the
higher the performance.

There are other non-functional aspects too, like responsiveness,
maintainability, etc.

> I can imagine tasks that need lower latency time, even in spite of
> small decrease of overall performance (I agree that the notion of
> "small" is very subjective). Sometimes it may be important for an
> application to switch more often between the threads.

That may be the case, but I'm not aware of any such
applications. Usually, people expect that the "system" keeps going
even if one of the threads block for a significant period of time
(e.g. while waiting for user input). If there is more than one thing
to do, people wish that all of those things get done ASAP.

In a real-time application, things to do have deadlines, however, it
is not necessary to switch forth and back between threads to meet the
deadlines. Instead, the scheduler should priorize the "most important"
things - which is a science on its own.

> As Dave said in [7], the big question is: how this patch would
> affect existing applications (if applied) ? The same question, I
> suppose, is asked before ANY change in python interpreter.

The big question is: where is the need for such a feature?


More information about the Python-list mailing list