RFR 8008378: FJP.commonPool creation within PrivilegedAction, and support parallelism 0 (JEP 155) (original) (raw)

Chris Hegarty chris.hegarty at oracle.com
Mon Feb 18 14:43:58 UTC 2013

As usual, changes from Doug, with some additional tests from me.

Access and parse properties, as well as construct common pool in a PrivilegedAction, explicitly ignoring any unparseable settings. This way any racy static creation by unprivileged clients rather than usual channels won't fail, while at the same time allowing better advice about managed construction (as in EE frameworks) to do anything that causes it to exist before starting other processing, as well as to, if applicable provide a thread-factory that itself uses PrivilegedAction or some such. This way, these frameworks remain in control over how much parallelism their users get.
For only the particular method FJP.execute(Runnable) (which is not usually used in FJ but must be supported), force an exception thrown by the Runnable to cause the corresponding worker to die (and possibly be replaced). This is among other things a small abuse guard: The normal FJ capture and reporting of an exception in the task object will never be seen, so at least the UncaughtExceptionHandler will trigger, at the cost of throwing away and creating a thread (that we normally otherwise avoid).

Specdiff:

-Chris.