[concurrency] Inside the Python GIL

[Jeremy Hylton]

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<jeremy.mcmillan at gmail.com> 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, skip at pobox.com 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
>> concurrency-sig at python.org
>> http://mail.python.org/mailman/listinfo/concurrency-sig
>
> _______________________________________________
> concurrency-sig mailing list
> concurrency-sig at python.org
> http://mail.python.org/mailman/listinfo/concurrency-sig
>