On 10/27/06, Tolkin, Steve <[EMAIL PROTECTED]> wrote: > Dear Ben, Bob et al., > Thanks for this thread. (It has a very high signal to noise > ratio, compared with many others.) > > Dear Everyone, > Since this started about Python, in a Perl discussion list, I am > wondering about whether Perl facilitate the kind of experimentation that > led to "stackless Python". http://www.stackless.com/ "An experimental > implementation that supports continuations, generators, microthreads, > and coroutines." > See also > http://www.onlamp.com/pub/a/python/2000/10/04/stackless-intro.html
Sorta. There are modules like http://search.cpan.org/~mlehmann/Coro-2.0/Coro.pm in Perl, but nobody has built a modified Perl for something like this. > Perhaps not, because this will be built into Perl 6. Well it will. :-) I suspect that out of the box the pugs implementation will be significantly more capable in this regard than the parrot one. That's a pretty safe bet actually. See http://www.perlmonks.org/?node_id=580042 for an idea of what the pugs implementation already does. > Perhaps not, because the Python community is different than the Perl > community in some fundamental way, e.g., there is only one version of > Perl. > > Perhaps not, because Continuations are a "Bad Thing". My dislike notwithstanding, continuations are a core feature of Perl 6. > I believe some disciplined way of doing concurrency is clearly needed, > and I do not think any of our current abstractions are good enough. > (They may work in theory, but not in practice, e.g. they are too hard to > reason about, or to debug.) Well I think that continuations are one of the worse possible abstractions out there. See the Perlmonks link for a better approach to concurrency. (Dunno how well it will work in Perl though.) See http://labs.google.com/papers/mapreduce.html for how Google handles the issue. > I can think of no better path than for Perl to get this right, and run > well on the multi-core CPU systems of the future. No matter how Perl handles this, for most of what I do with Perl, I can cheerfully ignore it. I'm not being flippant here. There are a number of good ways around the issue, or barriers to using Perl's solutions. They include: - Using Apache with pre-forked processes already takes advantage of all of the possible concurrency in a multi-core CPU without using any language support. - I/O bound jobs don't run any better on multiple CPUs than they do on one. - Mixing concurrency and communications with an outside process is a Bad Idea. So, for instance, you cannot use a database handle from inside multiple threads without confusing both you and the database (with disasterous results). Virtually everything I do is covered by one of those three cases, and therefore cannot take useful advantage of any further language support for concurrency that is added on. I suspect that many other Perl programmers are in the same boat. Cheers, Ben Cheers, Ben _______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
