Yeah, by "not sure I understand" means that I'd be interested to see how the GIL behaves for some other workloads. I have some angst about the number of abstraction layers in the std library for I/O, so I'm curious about how the interpreter would do as the number of I/O threads increases.
Jeremy On Fri, Jun 12, 2009 at 3:45 PM, Jeremy McMillan<[email protected]> wrote: > Proof is in the pudding. If you can cook up a load test, under what > conditions can you soak up all of your CPU's cycles? > > On Jun 12, 2009, at 12:39 PM, [email protected] wrote: > >> >> Jeremy> I'm not sure I understand how to distinguish between I/O bound >> Jeremy> threads and CPU bound threads. >> >> I don't know that we can (people writing bits of Python which operate on >> threads). I suspect a useful distinction though is that an I/O bound >> thread >> mostly gives up the CPU to wait on an I/O device, while a CPU bound thread >> is mostly "evicted" from the CPU by the OS scheduler. (Though I sort of >> suspect you already understand this textbook definition.) Is that what >> you're referring to by "not sure I understand"? >> >> Skip >> _______________________________________________ >> concurrency-sig mailing list >> [email protected] >> http://mail.python.org/mailman/listinfo/concurrency-sig > > _______________________________________________ > concurrency-sig mailing list > [email protected] > http://mail.python.org/mailman/listinfo/concurrency-sig > _______________________________________________ concurrency-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/concurrency-sig
