review of std.parallelism

[dsimcha]

On 3/19/2011 5:33 PM, Michel Fortin wrote:
> On 2011-03-19 15:36:24 -0400, dsimcha <dsimcha at 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.