[concurrency-interest] curious if there is a Local.java in the works for CompletableFutures like scala has

[Alex Otenko]

Why would someone want to rely on state they cannot control?

Is the idea to subvert some API that does not provide a way to pass state? This is strange especially in the context of Scala, where you can easily form tuples.

Alex

> On 22 May 2017, at 20:44, Martin Buchholz <martinrb at google.com> wrote:
> 
> There's not likely to be any support for local context anywhere in java.util.concurrent, but it seems not too hard to roll your own support with a custom executor to be used with CompletableFuture that kept track of any local context.
> 
> On Fri, May 19, 2017 at 1:16 PM, Pavel Rappo <pavel.rappo at oracle.com <mailto:pavel.rappo at oracle.com>> wrote:
> General questions on concurrency in Java should be asked here:
> 
>    http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest <http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest>
> 
> > On 18 May 2017, at 21:57, Dean Hiller <dhiller at twitter.com <mailto:dhiller at twitter.com>> wrote:
> >
> > Way more detail here...
> >
> > http://stackoverflow.com/questions/37933713/does-completablefuture-have-a-corresponding-local-context <http://stackoverflow.com/questions/37933713/does-completablefuture-have-a-corresponding-local-context>
> >
> > So I was wondering if this was going to be added at some point to the jdk
> > as I could not figure out how to set something so it was still available on
> > the thread at a later time when traversing async thenCompose, thenAccept.
> >
> > thanks,
> > Dean
> 
> 
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest