Error formatting macro: pagetree: java.lang.NullPointerException
Skip to end of metadata
Go to start of metadata
You are viewing an old version of this page. View the current version. Compare with Current  |   View Page History


Need ability to invoke tasks asynchronously at the bottom of core.async. And fast.


  • Executor interface
    • Need ability to invoke tasks asynchronously
      • Effectively ExecutorService.submit(Runnable)
    • May want ability to shutdown the executor?
  • Executor implementation(s)
    • Need some implementation to cover JDK 1.6, 1.7, 1.8
    • Possible implementations
      • ThreadPoolExecutor
      • ForkJoin 
    • Executor library version
      • Provide implementation without external dependency
        • Use what's in the JDK or
        • Repackage jsr166 into our own package (jsr166 is public domain)
      • Allow path for users to use a bleeding edge version
    • Configuration 
      • Both ThreadPoolExecutor and ForkJoin have a number of of possible configuration parameters
      • Provide good defaults but also let user change them


  • Do not need to provide general access to ForkJoin (fork, join, recursive computation, etc)
  • Do not need access to futures for tasks
  • Do not need task cancellation

Proposed solution

  • Define protocol for async task execution
    • (defprotocol Executor (exec `[e task]))
  • Provide several implementations
    • for ThreadPoolExecutor
    • for ForkJoinPool 
      • Repackage jsr166y into our own packages
      • Allow user to use jsr166e instead
  • Choose default implementation based on environment
    • Simplest: always use our own jsr166y version
    • Or possibly (for JDK 1.8): use java.util.concurrent.ForkJoinPool (effectively jsr166e)
  • Allow user to override the implementation we chose

The decision process for the executor to use will thus be to check for these in the following order and use the first match:

  1. (maybe?)  Check for jsr166e.ForkJoinPool (external JDK version - override path for the future?)
  2. Check for clojure.concurrent.ForkJoinPool (Clojure repackaged jsr166y) - Clojure 1.6+, JDK 1.6+
  3. Check for java.util.concurrent.ForkJoinPool (JDK built-in version) - Clojure 1.5, JDK 1.7+
  4. Check for jsr166y.ForkJoinPool (external JDK version) - Clojure 1.5, external jsr166 jar
  5. Fallback to Executor version - Clojure 1.5, no external jar

In all cases, users will have the choice of providing a custom Executor impl that uses whatever hard-coded thing they want in which case this process is moot.

Background / Reference


  • JSR 166 
    • jsr166x - included in JDK 1.6, does not contain ForkJoin
    • jsr166y - compiled with JDK 1.6, included in JDK 1.7. jsr166y jar has fixes past what is in the JDK 1.6.
    • jsr166e - compiled with JDK 1.8, to be included in JDK 1.8. jsr166e jar has fixes past what is in JDK 1.7. 
  • Scala solution
    • Repackage known version of jsr166y as scala.concurrent and include in the Scala language (Akka makes use of it from there)
      • Covers JDK 1.6+ (good) but does not contain the very latest updates for JDK 1.8 that are in jsr166e (bad)
      • When they have a version of Scala that requires JDK 1.7, they will presumably update to jsr166e
    • Akka has pluggable executor providers and using a custom one allows you to make use of jsr166e if you need it