micro-threading PEP proposal (long) -- take 2!
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. Tanks, Jerry S.
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.
Forgive the pedantry: do you mean "breathe", rather than "breath"? On Wed, Aug 27, 2008 at 6:42 PM, Bruce Frederiksen <dangyogi@gmail.com>wrote:
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.
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
Yes! Thanks! -bruce Andrew Akira Toulouse wrote:
Forgive the pedantry: do you mean "breathe", rather than "breath"?
On Wed, Aug 27, 2008 at 6:42 PM, Bruce Frederiksen <dangyogi@gmail.com <mailto:dangyogi@gmail.com>> wrote:
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
participants (3)
-
Andrew Akira Toulouse -
Bruce Frederiksen -
Jerry Spicklemire