On Sat, Jun 03, 2006 at 03:51:45PM -0700, Paul Hodges wrote:
: --- Ashley Winters <[EMAIL PROTECTED]> wrote:
: > On 6/2/06, Paul Hodges <[EMAIL PROTECTED]> wrote:
: > >
: > > my @answer = map { async { &_() } } @jobs;
: >
: > That still seems too explicit. I thought we had hyperoperators to
: > implictly parallelize for us:
: >
: > my @answer = @jobs.»();
: >
: > Which would run them in parallel automatically, if possible.
:
: Snazzy bit of syntactic shenanigans, that...and slick, if we're in that
: mode, but just to clarify, I *will* still be able to know whether or
: not something's going to thread? Or will it matter?
Shouldn't, if the hyperop is really promising that the calls won't
interact, and that's how hyper is currently defined. I think Best
Practices will not have hypers spawning huge interacting threads.
: Seems to me there will be times when I WANT a purely single-threaded
: system, even if I'm using hyperops -- in fact, especially if I'm using
: hyperops. Maybe we need a pragma to be able to step in and out as
: needed?
:
: { no threads;
: print @_.»();
: }
It seems a bit odd to use a construct for its syntactic sugar value but
take away its semantics...
If you just need ordering, this (or something like it) should serialize it:
print $_.() for @_;
Larry
