[Python-ideas] micro-threading PEP proposal (long) -- take 2!

Bruce Frederiksen dangyogi at gmail.com
Thu Aug 28 03:42:43 CEST 2008


In this case, you're misunderstanding :-).

What I meant by a "long running" micro_thread starving other 
micro-threads, was a micro_thread that doesn't do anything that would 
cause it to be suspended (e.g., I/O, sleep).

For example, calculating the number PI to 2000 digits will starve other 
micro_threads.

Each time a micro_thread does something which causes it to be suspended 
(like a file.read that needs to access the disk, a socket.recv or a 
time.sleep), other micro_threads may run.  So the first micro_thread 
doesn't cause the whole os-thread (generally the whole Python program) 
to be suspended, like it does now.

But if one micro_thread uses the CPU for a long time without doing any 
I/O, then other micro_threads are starved because micro_threads are 
non-preemptive (unlike os-threads).

I'm adding a "breath" function that allows responsible micro_threads to 
"come up for air" periodically, to give other micro_threads a chance to 
run.  But nothing forces a micro_thread to cooperate like this...

I hopes this helps to clear things up!

-bruce


Jerry Spicklemire wrote:
> Bruce wrote:
>
> "The micro_pipes use the C_deferreds to suspend the thread
> and allow other threads to run."
>
> http://mail.python.org/pipermail/python-ideas/2008-August/001848.html
>
>
> However, in the PEP you mention, among the short list of
> disadvantages:
>
> "since there is no preemption, a long running micro-thread 
> will starve other micro-threads"
>
> http://mail.python.org/pipermail/python-ideas/2008-August/001825.html
>
>
>
> Are these two point contradictory, or am I simply 
> misunderstanding, as usual.
>   



More information about the Python-ideas mailing list