Not resuming Virtual Threads?

[Ron Pressler]

Continuations will not be exposed to programmers directly, at least not at first, so 
this is not an issue. When we expose them then, depending on the form that will
take, we can revisit this question.

— Ron


On 3 July 2020 at 16:28:45, Alex Otenko (oleksandr.otenko at gmail.com) wrote:

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   
>