Accessing to Fiber State
volkan.yazici at gmail.com
Sun Dec 16 11:14:24 UTC 2018
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
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>
> 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.)
> > 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
> > fiber is indeed parked to avoid a race condition. The relevant fix for
> > plain Threads:
> > )
> 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?
More information about the loom-dev