Fiber API questions

[Fabio Tudone]

>
> I can't tell if you are looking for it to return the more general
> Future<V> instead CompletableFuture<V> or expecting Fiber to implement
> Future. In any case, you shouldn't need a reference to the Fiber object
> in this case.
>

What I'm looking for is a way to reference a "java.lang.Fiber" that can
produce a result.

My use case is that of (a reduced version of) the Quasar API that I'm
wrapping around the current Loom prototype (so I'm somewhat dealing with
the structured concurrency topic already); this will allow me to experiment
with the current Loom API, look for issues in Loom itself (through the
Quasar test suite and the existing use cases) and, later on, check how
3rd-party libraries behave on top of Loom (by porting existing Quasar
integrations) as well as compare how instrumentation-based Quasar and
"Quasar-Loom" perform relative to each other at various stages.

When wrapping "java.lang.Fiber" I can currently choose to either:

- Refer a "java.lang.Fiber", in which case I can support scheduling at a
later stage as well as "isAlive" (and generally rely upon the
"java.lang.Fiber"-specific API) but I have to go through some more work to
let it run a "Callable" (in general,  to get a result).
- Refer a "CompletableFuture", in that case I can only support immediate
scheduling and I don't have access to "java.lang.Fiber"-specific APIs
(currently only "isAlive" if I'm not mistaken).

I think a similar same dilemma will present itself to Loom API users,
especially if / when the "java.lang.Fiber"-specific API will be expanded.

An option I can think of is offering "java.lang.Fiber<V>(Callable<V>)"
constructors instead of "Runnable" ones (whoever needs to pass in a
"Runnable" can easily convert it to "Callable<Void>", or perhaps such an
utility could even be provided as part of the JDK to avoid the
proliferation of incompatible 3rd-party solutions) and have the current
non-static "schedule()" method return a "CompletableFuture<V>" rather than
"java.lang.Fiber" (chaining convenience would be lost though). This would
allow an user to both deal flexibly with scheduling and execution through
the "java.lang.Fiber" API and to deal with results through the
"CompletableFuture" API at the same time on a given "java.lang.Fiber"
instance; I think it would also dispense with the current static "schedule"
methods.

Thanks,
-- Fabio

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>