When executing hooks, it would be significantly faster to run hooks in parallel rather than serially.

Benefits

• Faster hook runs that scale with the number of processors on a machine

Costs

• The HookRunner class will need some serious rethinking to support the collection of hook statuses as they are completed in parallel
• This will change overcommit to be a multi-threaded application, so interrupt handling (and signal handlers) will need to handle cases gracefully. Testing this will be difficult.
• If Allow hooks to depend on other hooks #143 is implemented, parallelism is potentially hindered depending on the dependency graph. This also introduces complexity as we can no longer just run hooks in topological sort order, but would need to trigger dependent hooks to run once all their dependencies passed.

Questions

• What happens if a hook generates files during its run?
  This is a potentially big issue. Since we're now running hooks in parallel the temporary files generated by some hooks could potentially affect other hook runs. We may have to support a parallelize option which can be set to false to force serial execution in extreme cases
• What happens if a hook runs git commands?
  Similar to the file issue above, some git commands require exclusive access to the files in the .git directory during their run. We'll likely need a git helper (similar to execute) that serializes requests so hooks don't accidentally trample on each other

Feel free to leave comments and ask questions in this issue.