On 3/19/2011 5:33 PM, Michel Fortin wrote:
On 2011-03-19 15:36:24 -0400, dsimcha <dsim...@yahoo.com> said:
The only problem is that there's no easy, well-documented way to tell
from the return value of opApply whether it was a break, a goto, a
labeled break/continue, etc. This would be implementable only if I
changed the semantics of break to also throw. This might not be a bad
thing (IMHO any type of breaking out of a parallel foreach loop is
just silly) but others had asked for different semantics for break.
It's not that silly.
Essentially, what you'd express like this with a normal function taking
a delegate:
taskPool.apply([1,2,3], (int i) {
if (i == 1)
return;
// do some things
});
you'd express like this in a parallel foreach:
foreach (int i; parallel([1,2,3])) {
if (i == 1)
break;
// do some things
}
It's not following the semantics of break within a foreach, but it's
still useful to be able to return early from a function (from a loop
iteration in this case), so I see the use case for making 'break' do
what it does.
Using continue is well defined behavior and does exactly what I think
you're suggesting. The problem with break is that it's supposed to stop
all subsequent iterations of the loop from being executed, not just end
the current one early. This only makes sense in a serial context, where
"subsequent iterations" is well-defined. Currently break breaks from
the current work unit but continues executing all other work units. I
put this semantic in because I couldn't think of anything else to make
it do and someone (I don't remember who) asked for it. I have never
encountered a use case for it.
IMHO all early termination that affects subsequent loop iterations as
well (break, goto, labeled break and continue, but not regular continue)
should just throw because they make absolutely no sense in a parallel
context.
