* origin/master: Bump to version 0.9.5. Remove (failing) italics in command line sample. Conflicts: lib/rake/version.rb
* origin/master: Fix typo: messing => missing Document options for --trace and --backtrace.
…jbishop/rake into dashm * 'all-tasks-are-multitasks' of https://github.com/michaeljbishop/rake: Added -m option which changes all tasks into multitasks Conflicts: lib/rake/application.rb lib/rake/multi_task.rb
Small change to correct documentation for --execute-continue
The short version specified the wrong mnemonic.
Adds a new method `Rake::Task#invoke_prerequisites_concurrently`. `Rake::MultiTask#invoke_prerequisites` always calls `Rake::Task#invoke_prerequisites_concurrently` and now `Rake::Task#invoke_prerequisites` will call it when `Rake.application.options.always_multitask == true`. Passing `-m` at the command-line sets `Rake.application.options.always_multitask` to `true`
Rake now has a thread_pool implementation which returns futures when passed args and a block. MultiTask has been changed to ask the thread pool for a list of futures in which inside each a prerequisite is completed. MultiTask then waits on each future until it is complete. The number of threads in the pool is controlled with the new -j option at the command-line. The thread pool is now a member of Rake.application and rakefile authors can request futures for their own operations, participating in the pool. The thread pool is special in that it will spawn a new thread when a thread in the pool is sleeping because it is waiting for a future being completed by another thread. When the new thread is finished, the pool size will shrink to where it was previously. With this change, the pool always has a number of threads actively doing work (that number being equal to the -j parameter). This commit also includes documentation for the new -j parameter and a test for the ThreadPool implementation.