Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #34016 > unrolled thread

ExecutorService.shutdown ambiguity

Back to article view | Back to comp.lang.java.programmer

Contents

  ExecutorService.shutdown ambiguity Roedy Green <see_website@mindprod.com.invalid> - 2016-03-18 12:37 -0700
    Re: ExecutorService.shutdown ambiguity Jeff Higgins <jeff@invalid.invalid> - 2016-03-18 20:52 +0000
    Re: ExecutorService.shutdown ambiguity v_borchert@despammed.com (Volker Borchert) - 2016-03-18 20:20 +0000
    Re: ExecutorService.shutdown ambiguity Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2016-03-19 23:07 -0700

#34016 — ExecutorService.shutdown ambiguity

Here is the JavaDoc for ExecutorService.shutdown.
To me it is ambiguous. How do you read it?

What happens to a task in queue? What happens to a task that is
executing?

     * Initiates an orderly shutdown in which previously submitted
     * tasks are executed, but no new tasks will be accepted.
     * Invocation has no additional effect if already shut down.
     *
     * <p>This method does not wait for previously submitted tasks to
     * complete execution.  Use {@link #awaitTermination
awaitTermination}
     * to do that.
     *
     * @throws SecurityException if a security manager exists and
     *         shutting down this ExecutorService may manipulate
     *         threads that the caller is not permitted to modify
     *         because it does not hold {@link
     *         java.lang.RuntimePermission}{@code ("modifyThread")},
     *         or the security manager's {@code checkAccess} method
     *         denies access.
     */
    void shutdown();
-- 
Roedy Green Canadian Mind Products http://mindprod.com
The standard definition of AI is that which we don’t understand.
~ Bill Joy (born:1954-11-08 age:61), co-inventor of Java.

[toc] | [next] | [standalone]

#34017

On Fri, 18 Mar 2016 12:37:13 -0700, Roedy Green wrote:

> Here is the JavaDoc for ExecutorService.shutdown.
> To me it is ambiguous. How do you read it?
> 
> What happens to a task in queue? 

"... previously submitted tasks are executed ..."

> What happens to a task that is executing?

Presumably it continues executing.
However ExecutorService.shutdown() returns without awaiting completion.
 
> 
>      * Initiates an orderly shutdown in which previously submitted *
>      tasks are executed, but no new tasks will be accepted.
>      * Invocation has no additional effect if already shut down.
>      *
>      * <p>This method does not wait for previously submitted tasks to *
>      complete execution.  Use {@link #awaitTermination
> awaitTermination}
>      * to do that.
>      *
>      * @throws SecurityException if a security manager exists and *     
>         shutting down this ExecutorService may manipulate *        
>      threads that the caller is not permitted to modify *        
>      because it does not hold {@link *        
>      java.lang.RuntimePermission}{@code ("modifyThread")}, *         or
>      the security manager's {@code checkAccess} method *         denies
>      access.
>      */
>     void shutdown();

[toc] | [prev] | [next] | [standalone]

#34018

Roedy Green wrote:
> Here is the JavaDoc for ExecutorService.shutdown.
> To me it is ambiguous. How do you read it?
> 
> What happens to a task in queue? What happens to a task that is
> executing?
> 
>      * Initiates an orderly shutdown in which previously submitted
>      * tasks are executed, but no new tasks will be accepted.
>      * Invocation has no additional effect if already shut down.
>      *
>      * <p>This method does not wait for previously submitted tasks to
>      * complete execution.  Use {@link #awaitTermination
> awaitTermination}
>      * to do that.
>      *
>      * @throws SecurityException if a security manager exists and
>      *         shutting down this ExecutorService may manipulate
>      *         threads that the caller is not permitted to modify
>      *         because it does not hold {@link
>      *         java.lang.RuntimePermission}{@code ("modifyThread")},
>      *         or the security manager's {@code checkAccess} method
>      *         denies access.
>      */
>     void shutdown();

I'd expect: They will be executed normally. Therefore, you shouldn't
do anything really drastic like System.exit() until awaitTermination()
has returned.

-- 

"I'm a doctor, not a mechanic." Dr Leonard McCoy <mccoy@ncc1701.starfleet.fed>
"I'm a mechanic, not a doctor." Volker Borchert  <v_borchert@despammed.com>

[toc] | [prev] | [next] | [standalone]

#34019

In article <02moebljqki662mrgr8f6ga85uhj2lt14s@4ax.com>,
 Roedy Green <see_website@mindprod.com.invalid> wrote:

> Here is the JavaDoc for ExecutorService.shutdown.
> To me it is ambiguous. How do you read it?
> 
> What happens to a task in queue? What happens to a task that is
> executing?
> 
>      * Initiates an orderly shutdown in which previously submitted
>      * tasks are executed, but no new tasks will be accepted.
>      * Invocation has no additional effect if already shut down.
>      *
>      * <p>This method does not wait for previously submitted tasks to
>      * complete execution.  Use {@link #awaitTermination
> awaitTermination}
>      * to do that.
>      *
>      * @throws SecurityException if a security manager exists and
>      *         shutting down this ExecutorService may manipulate
>      *         threads that the caller is not permitted to modify
>      *         because it does not hold {@link
>      *         java.lang.RuntimePermission}{@code ("modifyThread")},
>      *         or the security manager's {@code checkAccess} method
>      *         denies access.
>      */
>     void shutdown();

Tasks are not started and not aborted.

Calling shutdown() on a running ScheduledThreadPoolExecutor in some JVMs 
will cause a spin loop or infinite loop.  The original Doug Lea 
Executors are rather buggy.  (They're very hard to write, especially 
with a bloated API to support.)

-- 
I will not see posts from astraweb, theremailer, dizum, or google
because they host Usenet flooders.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web