RFR [9] 8056152 API to create Threads that do not inherit InheritableThreadLocals

Chris Hegarty chris.hegarty at oracle.com
Tue Dec 8 14:50:55 UTC 2015


On 8 Dec 2015, at 14:33, Roger Riggs <Roger.Riggs at oracle.com> wrote:

> Hi Chris,
> 
> Supporting the use case in Thread is a good addition.

Thanks.

> Adding an argument to the most flexible constructor of Thread bulks up
> an already heavy weight constructor.  Look at the cases being replaced,
> none of them use all of the arguments.  The stackSize, for example, is rarely
> used and is nearly useless due to its implementation dependencies.

Right. The motivation for adding an additional constructor that accepts a
superset of arguments is for maximum flexibility. Since this is targeted at
the advanced user, then it should be ok, but I agree it looks a little unwieldy.

> Would you consider using a static Factory method (aptly named) instead
> of a constructor?

Possibly, I went down the constructor route for consistency with what is
already there. The usage pattern of extending Thread is also very common.

-Chris.

> Roger
> 
> 
> On 12/08/2015 09:15 AM, Chris Hegarty wrote:
>> Many threads created by the platform are short lived and perform some
>> simple async operation on behalf of the platform. These threads typically
>> use/extend sun.misc.ManagedLocalsThread. This is a convenient internal
>> API that can be used to create threads that do not wish to inherit initial
>> values from inheritable thread-local variables.
>> 
>> I'd like to propose an additional java.lang.Thread constructor that exposes
>> the ability to explicitly "opt out" of inheriting these initial values ( from
>> inheritable thread-local variables ). This seems like useful general
>> functionality, given the amount of usage in the JDK of the internal API.
>> 
>> This new public API can then be used to replace usages of the internal
>> sun.misc.ManagedLocalsThread. As part of this bug I've only retrofitted
>> the usage in the sources of the base module. Other modules can be done
>> as a follow up.
>> 
>> Webrev:
>>   http://cr.openjdk.java.net/~chegar/8056152/00/webrev/
>> 
>> -Chris.
>> 
>> [1] https://bugs.openjdk.java.net/browse/JDK-8056152
> 




More information about the core-libs-dev mailing list