Accessing to Fiber State

[Volkan Yazıcı]

Ok, I see. Thanks for the clarification. I will keep on watching the
mailing list for any developments on this issue.

I am indeed using a custom scheduler, which is a single-threaded fixed
pool:
https://github.com/vy/fiber-test/blob/master/java-loom/src/main/java/com/vlkan/fibertest/ring/JavaFiberRingBenchmark.java
I particularly chose this approach, since I don't want to benchmark
schedulers but the context switch efficiency of different approaches, which
constitute the gist of delimited continuations, IMHO.

On Sun, Dec 16, 2018 at 8:55 AM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 15/12/2018 22:33, Volkan Yazıcı wrote:
> > Hello,
> >
> > AFAIU from the source code, one is supposed to create fibers via
> > Fiber.schedule(), that is not via extending Fiber, which is allowed for
> > Threads. (I think this behavior has been introduced pretty recently.)
> Using
> > factory method makes it impossible to access to Fiber#getState(). Am I
> > missing something? How can we access to the state of a Fiber?
> >
> > (For those interested, the context is as follows: I need to confirm that
> a
> > fiber is indeed parked to avoid a race condition. The relevant fix for
> > plain Threads:
> >
> https://github.com/vy/fiber-test/commit/929a898d387114a2721282ef5f789288e1aed453
> > )
> There hasn't been any work to date on monitoring and management support
> so still TBD whether fiber states will be exposed or whether it will be
> something completely different. It might be that only a small subset of
> fibers are interesting to monitor for example. The non-public
> Fiber.getState method you found is to support Thread.getState, e.g. a
> task executed by a fiber leaks Thread.currentThread() to something that
> monitors its state with Thread::getState.
>
> For your usage, is this your own scheduler where the task completes when
> the fiber parks?
>
> -Alan
>