On 3/24/2011 8:03 AM, Michel Fortin wrote:
On 2011-03-24 03:29:52 -0400, Sönke Ludwig
<[email protected]> said:
Hm depending on the way the pool is used, it might be a better default
to have the number of threads equal the number of cpu cores. In my
experience the control thread is mostly either waiting for tasks or
processing messages and blocking in between so it rarely uses a full
core, wasting the available computation time in this case.
However, I'm not really sure if it is like this for the majority of
all applications or if there are more cases where the control thread
will continue to do computations in parallel. Maybe we could collect
some opinions on this?
The current default is good for command line applications where the main
thread generally blocks while you're doing your work. The default you're
proposing is good when you're using the task pool to pile up tasks to
perform in background, which is generally what you do in an event-driven
application. The current default is good to keeps simpler the simpler
programs which are more linear in nature.
My use case is like yours: a event-driven main thread which starts tasks
to be performed in the background.
Please review the changes carefully, then, because this is a use case I
know next to nothing about and didn't design for. 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.
