RFR: 8290036: Define and specify Runtime shutdown sequence [v7]

David Holmes dholmes at openjdk.org
Thu Sep 1 06:33:13 UTC 2022


On Mon, 29 Aug 2022 08:21:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I don't think we need to distinguish between platform and virtual threads here at all. Isn't it the case that virtual threads also have a run() method and they too terminate when run() completes as described (together with UEH)? The fact most Thread run() methods call something else's run() method is immaterial. We don't know what a run() method will do, but whatever it is once it completes then the thread has terminated.
>
> There are subtle differences (invoking a virtual Thread's run method directly does no nothing) but that is too much detail and would confusing to say anything about in the introduction paragraphs.
> 
> The following is closer to what I think we should have. The existing paragraph 2 describes starting a thread so this is where the Thread.run method is introduced. Paragraph 3 follows to describe termination.
> 
> 
>  * <p> {@code Thread} defines constructors and a {@link Builder} to create threads.
>  * {@linkplain #start() Starting} a thread schedules it to execute its {@link #run() run}
>  * method. The newly started thread executes concurrently with the thread that caused
>  * it to start.
>  *
>  * <p> A thread <i>terminates</i> if either its {@code run} method completes normally,
>  * or if its {@code run} method completes abruptly and the appropriate {@linkplain
>  * Thread.UncaughtExceptionHandler uncaught exception handler} completes normally or
>  * abruptly. With no code left to run, the thread has completed execution. Thread
>  * defines the {@link #join() join} method to wait for a thread to terminate.

That sounds reasonable to me.

-------------

PR: https://git.openjdk.org/jdk/pull/9437


More information about the core-libs-dev mailing list