If Scheme is so good why MIT drops it?

Jean-Paul Calderone exarkun at divmod.com
Wed Jul 22 22:53:17 CEST 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.


More information about the Python-list mailing list