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.
