Not resuming Virtual Threads?

[David Holmes]

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
>