RFR 8008378: FJP.commonPool creation within PrivilegedAction, and support parallelism 0 (JEP 155)
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.
1. 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.
2. 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:
http://cr.openjdk.java.net/~chegar/8008378/specdiff.00/overview-summary.html
Webrev:
http://cr.openjdk.java.net/~chegar/8008378/webrev.00/webrev/
-Chris.
More information about the core-libs-dev
mailing list