[concurrency-interest] map over j.u.c.CompletableFuture with strict threading semantics

Viktor Klang viktor.klang at gmail.com
Fri Oct 20 14:06:16 EDT 2017


Dimitar,

Just a note: I realized that you can probably get to what you want by
controlling injecting a "valve"—CompletableFuture, and only complete that
once you want the transformations to be applied:

Pseudocode (since I'm having lunch):
enum Trigger { On; }
CompletableFuture<X> upstream = …
CompletableFuture<Trigger> upstreamTrigger = new
CompletableFuture<Trigger>()

CompletableFuture<Y> result = upstream.thenCombineAsync(upstreamTrigger,
(x, discard) -> x, YOUR_INTENDED_EXECUTOR).thenApply(…).thenCompose(…)…

upstreamTrigger.complete(Trigger.On); // this will trigger the execution of
the transformations on YOUR_INTENDED_EXECUTOR regardless of what
transformations are added to `result` as long as they HAPPEN-BEFORE the
execution of this line.

YMMV,

√



On Fri, Oct 20, 2017 at 5:32 PM, Dimitar Georgiev <
dimitar.georgiev.bg at gmail.com> wrote:

> Thanks Viktor! I had not thought of it this way, and you are absolutely
> right.
>
> I hope it is okay to expand the discussion a little bit and go a bit
> off-topic from j.u.c. Viktor probably already sees where this is
> going. Next is flatMap:
>
> public static <A, B> CompletableFuture<B> flatMap(CompletableFuture<A>
> future, Function<A, CompletableFuture<B>> f);
>
> Semantics my app requires here: if the result of f() is completed on a
> new threading context, I want subsequent map / flatMap operations to
> use that context. If not (if the result of f() is pure, i.e. of the
> form new CompletableFuture<>().complete(value)), continue in the same
> threading context.
>
>  Viktor, your remark leads me to think there is no sane way to achieve
> this semantics with an eager future implementation such as
> CompletableFuture. I would need something lazy which is a description,
> creating the thing be referentially transparent, and
> submission/execution be decoupled from creating the thing.
>
> To finish the off-topic with the actual question:
> - Does such a thing exist in the Java ecosystem at all? I know it does
> in Scala, but I need a Java alternative.
>
> P.S. I found a couple of months ago https://github.com/traneio/future.
> A claim is made that the threading semantics are what I just
> described, but it is an eager future. I will look into the
> implementation in the coming days; I expect it to be something along
> the "workaround" Viktor described. Myself, I don't feel I am smart
> enough or have the testing and formal verification tools to go down
> that path...
>
>
>
>
>
>
> On 20 October 2017 at 17:52, Viktor Klang <viktor.klang at gmail.com> wrote:
> > Hi Dimitar,
> >
> > In general this is not possible, nor desirable, since completion is
> likely
> > to happen *before* a transformation is added.
> >
> > However, there is nothing technical which prevents you to create an
> > implementation of CompletionStage which stores a reference to the
> Executor
> > to be used, and runs transformations which are applied to it on that
> > Executor unless some other Executor is specified.
> >
> > --
> > Cheers,
> > √
> >
> >
> > On Oct 20, 2017 09:41, "Dimitar Georgiev" <dimitar.georgiev.bg at gmail.com
> >
> > wrote:
> >
> > Sorry if this has already been discussed.
> >
> > I need to implement the following function:
> >
> > public static <A, B> CompletableFuture<B> map(CompletableFuture<A>
> > upstream, Function<A, B> f);
> >
> > It's pretty apparent what the function does. However, it has the
> > requirement that f() be always executed in the thread where upstream
> > is completed. (That is, if upstream is completed non-exceptionally,
> > since if it was not, f will not be called so there is no threading
> > semantics concerning f)
> >
> > Is this possible with j.u.c.CompletableFuture?
> >
> > Regards, Dimitar
> > _______________________________________________
> > Concurrency-interest mailing list
> > Concurrency-interest at cs.oswego.edu
> > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> >
> >
>



-- 
Cheers,
√
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20171020/f5fcacdb/attachment.html>


More information about the Concurrency-interest mailing list