"stopping" misbehaving fibers

[Mark Raynsford]

On 2020-05-10T11:59:24 +0100
Alan Bateman <Alan.Bateman at oracle.com> wrote:

> On 10/05/2020 10:38, Mark Raynsford wrote:
> >
> > 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.

OK, thanks! It's a little unfortunate, but understandable given the
reality of how these things work on modern architecutres.

For my own case, I was thinking in terms of a little teaching tool for
operating systems. Consider the case where we have a simulator that
simulates an operating system kernel and userland processes. It seems
like there could be a nice 1:1 correspondence between simulated
userland processes and fibers. However, we'd obviously like to be able
to simulate what happens in real life when a process goes into an
infinite loop (the process is eventually preempted by a hardware
interrupt, and the kernel schedules something else to run).

It sounds like custom schedulers would very much apply here, given that
that's pretty much exactly what we'd be representing at the application
level. :)

-- 
Mark Raynsford | https://www.io7m.com