"stopping" misbehaving fibers

[Alan Bateman]

On 10/05/2020 10:38, Mark Raynsford wrote:
> Hello!
>
> In the current (pre-Loom) thread model, if a thread goes into an
> infinite loop without making any blocking calls and without consuming
> any stack space (such that a StackOverflowError would eventually be
> raised), then there's nothing we can do about this. The thread will
> burn CPU time, subject to OS scheduling, until the VM process is killed
> and restarted.
>
> Is the same also true of Fibers? I understand that any time a fiber
> makes a blocking call, the fiber is parked. Is it possible to otherwise
> preempt or pause a fiber that isn't making it to a point where it will
> yield (either due to bugs or malicious intent)?
>
This hasn't changed. If something buggy goes into a loop and it is not 
polling something that tells it to finish (and unwind) then you are out 
of luck. The write-up  with the reasons why Thread stop and 
suspend/resume are unsafe and deadlock prone all apply (the terminally 
deprecated methods on Throw throw UOE if you invoke then on a virtual 
thread btw).

That said, there are examples where it might be interesting to 
forcefully preempt. There was a good discussion about this at JVMLS 2018 
where someone had an example that involved a potentially long running 
task that they might let run for a bit, maybe pre-empting it after some 
time and scheduling it to continue later when there are more resources 
available. There is some underlying support in the current prototype for 
forced preemption that uses safepoints and the thread-local handshake 
mechanism. No current plans to expose anything right now but might be 
something to come back to in the future in the context of custom schedulers.

-Alan.