Goals

• deterministic – calling quick-check with parallel opts gives the same answer as without

  • we have to give up some determinism though, because I don't think we could reasonably
    say that the reporter-fn will be called the same way every time, or even that
    the :num-tests value returned should always be the same

• does the best possible thing on the jvm w.r.t. things hanging

• is it necessary to have some sort of dynamic var with a thread id or something similar,
  so users can use it to coordinate usage of global resources? alternatively they could
  use a ThreadLocal by hand, or a pool

Issues

• Is this really worth it? The downside is it makes the API and impl of quick-check more complex, and arguably most use cases could be served by calling quick-check multiple times from separate threads; would a generic test-suite parallelizer do the job for most people?