On 2011-03-24 09:46:01 -0400, dsimcha <dsim...@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.for...@michelf.com http://michelf.com/
