std.parallelism changes done

[dsimcha]

On 3/24/2011 10:34 AM, Michel Fortin wrote:
>
> One thing I'd want to be sure however is that you can use a parallel
> foreach from within a task. So if you have one or two tasks that could
> benefit from data parallelism it won't bring the whole system down. From
> the API I don't think it'll be a problem.

Right.  This is completely do-able and I've done it before in practice.

>
>
>> I added a few (previously discussed) things to help this use case, at
>> your request. BTW, one hint that I'd like to mention (not sure how to
>> work it into the docs) is that, if you **don't** want to execute a
>> task in the current thread if it's not started, but want its return
>> value if it's done (as may be the case when you need threading for
>> responsiveness, not throughput), you can call Task.done to check if
>> it's done, and then Task.spinForce() to get the return value after you
>> know it's already done.
>
> The problem with using Task.done that way is that it requires polling.
> It might be appropriate in some cases, but in general you want to
> receive a message telling you when the task is done. That's not really
> complicated however: all the task has to do is send back its result
> through std.concurrency's "send" or through some other event dispatch
> mechanism instead of through a return statement.

Sounds like a good plan.  In general, I've tried to keep the design of 
std.parallelism simple but composable.  I have no intention of 
re-implementing any kind of message system when std.concurrency already 
does this well.  If this is what you want to do, though, maybe you 
should just use std.concurrency.  I'm not sure what std.parallelism 
would add.

>
> So I hope your tasks can accept "void" as a return type.

Yes, this works.