On 8 Dec 2015, at 14:33, Roger Riggs <roger.ri...@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 >
