If Scheme is so good why MIT drops it?

[Carl Banks]

On Jul 22, 1:53 pm, Jean-Paul Calderone <exar... at divmod.com> wrote:
> On Wed, 22 Jul 2009 12:35:52 -0700 (PDT), Carl Banks <pavlovevide... 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.

I guess you would know, but polling on all of these at once has got
use more obscure calls than I'm familiar with.

On Linux I can use select to wait for pipes and sockets, but not SysV
semaphores AFAIK.  On Windows it's well known that select only works
for sockets.

So do all these OSes have some kind of __mega_unifying_poll system
call that works for anything that might possibly block, that you can
exploit from a user process?


> >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.

Using native theads with blocking allows one to run a background
calculation without burdening it to yield often enough to provide
sufficient response times for other operations (which may or may not
be convenient to do).

Even if it's possible to accomplish arbitrary background processing
without native threading (and it is not, because the background
calculations could be performed by a library you don't control whose
author didn't bother yielding at any point), you cannot reasonably
claim native threads have no advantage in this case.


Carl Banks