On Mon, 29 Aug 2022 08:21:02 GMT, Alan Bateman <[email protected]> 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
