On Mon, 29 Aug 2022 08:21:02 GMT, Alan Bateman <al...@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