If Scheme is so good why MIT drops it?
Jean-Paul Calderone
exarkun at divmod.com
Wed Jul 22 16:53:17 EDT 2009
On Wed, 22 Jul 2009 12:35:52 -0700 (PDT), Carl Banks <pavlovevidence at gmail.com> wrote:
>On Jul 22, 12:04 pm, Paul Rubin <http://phr...@NOSPAM.invalid> wrote:
>> Carl Banks <pavlovevide... at gmail.com> writes:
>> > > Why is that such an advantage? Green threads work fine if you just
>> > > organize the i/o system to never block.
>>
>> > Because then I don't have to organize the I/O system never to block.
>>
>> We're talking about what a language implementation does behind the
>> scenes, I thought.
>
>No we're not, we are talking about the whether GIL completely or only
>partially undermines the use of native threads on Python.
>
>I don't think your fantasy async-only all-green-thread langauge
>implementation is possible anyway. How would you wait on a pipe in
>one thread, a socket in another, a semaphore in a third? (Are there
>any popular OSes that offer a unified polling interface to all
>possible synchronizations?)
Every OS I can think of can support the three examples you gave here.
>And what do you do about drivers or
>libraries that make underlying blocking calls?
Certainly a point to consider.
>What if you have a busy calculation going on in the background?
What if you do? Are you suggesting this would somehow prevent I/O from
being serviced? I'm not sure why, as long as the implementation pays
attention to I/O events.
Jean-Paul
More information about the Python-list
mailing list