Microthreads without Stackless?
fakeaddress at nowhere.org
Sat Sep 18 06:51:24 CEST 2004
David Mertz, Ph.D. wrote:
> Yeah... I know Bryan thinks that's a problem. Mostly because he
> doesn't actually know what a coroutine is. But it's true that the
> scheduled coroutines I present in the mentioned article are always
> "flat" (hmm... didn't I read somewhere that: "Flat is better than
Any chance, at this point, that I could get forgiveness for my
tone, yet continue the discussion? I misunderstood the nature
of the articles, and the way I put things was inappropriate for
this forum. I particularly apologize for my first sentence in
this thread; that was no way to talk about a Python enthusiast.
> But that's actually just what coroutines ARE. Bryan seems to want
> some kind of hybrid between actual coroutines and a call stack. Which
> isn't necessarily bad. And is probably something various
> languages--like Perl 6--do support.
I'm genuinely surprised to find we disagree on what constitutes
coroutine or micro/weightless threads. I really did read
David's articles, and I thought I was with him on that. The
article he cited brings up the distinction "Coroutines And Semi-
coroutines", and I think it implies that full co-routines are
not limited to a single level.
Perl 6 does/will support what I think of as coroutines, as do a
number of other languages. Perl 6 features continuations, which
are even more powerful and open new cans of worms.
> It might also be something that your greenlets support. It looks like
> an interesting project, and I'll have to take a look at it soon, and
> maybe do an article on them. But I suspect that even there, Bryan
> won't get everything he wants with his additional constraint that he
> not have to "change any code."
I'd be happy to see Greenlets, or the equivalent, become a
standard part of Python. My constraint isn't as strong as that
I not have to change any code; I want to limit and localize the
> [...] I'll
> point out that my coroutine schedules probably does require a
> little reorganization of more traditional call-chain code.
> That won't work with my generator/coroutines using a scheduler.
> 'child()' can only yield one level up, not arbitrarily. But you
> can "flatten" the exact same flow by making it: [...]
The extent and nature of the reorganization is the center of the
issue. Modern programs have to handle events from multiple
sources at once. I'd argue that generators offer, at best, a
modest improvement over the state-machine method. I vastly
prefer the process/thread/stackful-coroutine approach, and I'm
prepared to give reasons why.
More information about the Python-list