[concurrency-interest] ScheduledThreadPoolExecutor and shutdown permission check.

Joe Bowbeer joe.bowbeer at gmail.com
Tue Apr 29 21:21:03 EDT 2008


On Tue, Apr 29, 2008 at 10:29 AM, Gregg Wonderly wrote:
> I have a STPE that I use in an applet.  At applet shutdown, I'd like to shutdown
>  the executor, but alas it requests a Permission check for a RuntimePermission
>  that I don't have in an unsigned applet.  It seems kind of silly to demand this
>  permission when no other thread management permission exist in the JDK for
>  applets.  Am I missing something in consideration of this issue?
>

Interesting.  So the exception is from TPE.shutdown() when it calls
checkPermission?

    private static final RuntimePermission shutdownPerm =
        new RuntimePermission("modifyThread");

    SecurityManager security = System.getSecurityManager();
    if (security != null)
        security.checkPermission(shutdownPerm);

Before checking to see if the current thread can interrupt the workers
-- even if none of the workers will actually be interrupted...

    if (security != null) { // Check if caller can modify our threads
        for (Worker w : workers)
            security.checkAccess(w.thread);
    }

The rationale is here

     * [ ... ] we must cooperate
     * with the security manager (if present), which may implement
     * policies that make more sense for operations on Threads
     * than they do for ThreadPools. This requires 3 steps:
     *
     * 1. Making sure caller has permission to shut down threads
     * in general (see shutdownPerm).
     *
     * 2. If (1) passes, making sure the caller is allowed to
     * modify each of our threads. This might not be true even if
     * first check passed, if the SecurityManager treats some
     * threads specially. If this check passes, then we can try
     * to set runState.
     *
     * 3. If both (1) and (2) pass, dealing with inconsistent
     * security managers that allow checkAccess but then throw a
     * SecurityException when interrupt() is invoked.  In this
     * third case, because we have already set runState, we can
     * only try to back out from the shutdown as cleanly as
     * possible. Some workers may have been killed but we remain
     * in non-shutdown state (which may entail tryTerminate from
     * workerDone starting a new worker to maintain liveness.)

What should it do?

--Joe


More information about the Concurrency-interest mailing list