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).



More information about the core-libs-dev mailing list