std.parallelism changes done

[Michel Fortin]

On 2011-03-24 09:46:01 -0400, dsimcha <dsimcha at yahoo.com> said:

> Please review the changes carefully, then, because this is a use case I 
> know next to nothing about and didn't design for.

Well, it's practically the same thing except you never want to execute 
a task in the main thread, because the main thread acts more like a 
coordinator for various things and the coordinator must stay responsive.

And since your main thread might be creating various kind of tasks you 
need a way to priorize some tasks over others. I think creating a few 
task pools with various priority and relying on OS thread scheduling 
would be adequate in most cases, but I haven't tried.

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.


> 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.

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


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/