Not resuming Virtual Threads?

[Alex Otenko]

A similar discussion happened before about try-finally.

Diagnosability of issues with GCed continuations that lose a stack with
finally clauses is important. Unlike a stuck thread, we'll get no clue.

Alex

On Fri, 3 Jul 2020, 13:39 Ron Pressler, <ron.pressler at oracle.com> wrote:

> Hi.
>
> As Alan explains, a live virtual thread is also always reachable while it
> is alive.
> Unlike platform threads, however, a virtual thread could become unreachable
> due to a bug in an implementation of a scheduler, a concurrency constructs
> or
> an IO construct, whether in the core-libraries or in a third-party
> implementation.
>
> My point was merely that even when such a bug occurs, while certainly
> undesirable, no guarantees made by the Java spec are broken (or, at least,
> they shouldn’t be). Semantically speaking, the effect of such a bug would
> be the
> same as that of a thread sleeping forever, with an additional ill-effect:
> observability
> tools may not be able to locate the errant virtual thread. This
> observability
> problem could hypothetically be ameliorated by synchronization constructs
> recording owning threads, making this situation easier to detect, but
> given that it
> can arise only due to a bug in the first place, then there is no guarantee
> that the
> same buggy construct would record the problem correctly, either.
>
> — Ron
>
>
> On 3 July 2020 at 03:06:19, David Holmes (david.holmes at oracle.com) wrote:
>
> Hi Ron,
>
> On 3/07/2020 4:05 am, Ron Pressler wrote:
> > That could happen if you write your own scheduler or some
> synchronization
> > construct (like a lock). In that case, the virtual thread (and
> associated
> > continuation) will be garbage-collected. From a semantics perspective,
> it
> > is the same as sleeping forever. Java makes no liveness guarantees so
> this
> > does not violate any existing ones.
>
> A Thread sleeping forever does not allow the Thread or its Runnable or
> any other reachable object to garbage-collected. Can you please clarify
> what the lifecycle of a virtual thread is and how that relates to its
> reachability?
>
> For reference a regular Thread is always logically reachable from its
> ThreadGroup, until it terminates. And ThreadGroups with active threads
> are reachable from their parent ThreadGroups. Hence all live threads are
> always reachable.
>
> Thanks,
> David
>
> >
> > But yeah, this can only happen as a result of a bug in a scheduler or a
> > synchronization construct, and certainly inadvisable to do
> intentionally.
> >
> > — Ron
> >
> >
> > On 2 July 2020 at 18:45:55, Johannes Kuhn (info at j-kuhn.de) wrote:
> >
> > After playing around with Virtual Threads a bit, I got to the question:
> > What happens if you don't resume a virtual thread?
> >
> > This could be either done by accident - single thread carrier, that
> > waits on an other virtual thread that should be executed on the same
> > carrier, but the virtual thread is pinned -
> > or on purpose, like not iterating over all elements in my Generator
> > example[1]. Or closing the executor once you got an answer.
> >
> > What happens with those Continuations? Can they be garbage collected?
> > What about held locks? How is this different from Thread.suspend?
> > Isn't that inherently dangerous?
> >
> > Just trying to get a better understanding of the model here.
> >
> > - Johannes
> >
> > [1]: https://gist.github.com/DasBrain/abfdaa44b44d898f5d3c3888619eb49b
> >
>