On 12/13/18 7:36 AM, Patrick Reinhart wrote: > Now the special case of using those special threads with no permission > are only created when the ForkJoinPool is initialized with a security > manager installed at this point of time. If the security manager will be > installed later, it has not impact what so ever (this is my actual > work-around the problem for now)
Dynamically installing a security manager encounters races that at best need a lot of care to manage. This is an issue in several contexts (not just thread pools). Sorry that I don't know of a general solution. > > Even if the security manager is enabled before the initialize of the > ForkJoinPool not all work is delegated to InnocuousForkJoinWorkerThread > instances (sometimes it picks the main thread instead, that has not the > restrictions, what I think should not be the case and is a potential > security leak too) The rationale is that parallel workers should not have more permissions than callers, but possibly fewer. > > Why is this done this way and the change of the context class loader or > uncaught exception handler not checked by the actual security manager > instead? Could you explain what you would like to have happen? -Doug
