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

Ah, this question comes up once in a while, the biggest questions in my mind are: 1) It's easy to lose context when intermediate libraries/Executors get involved, how does the developer detect and fix it? 2) It's unclear what fan-in behaviors like zip, merge etc mean in terms of what the local

Re: We need to add blocking methods to CompletionStage!

On Sep 27, 2016 01:18, "Martin Buchholz" <marti...@google.com> wrote: > > > > On Mon, Sep 26, 2016 at 7:55 AM, Viktor Klang <viktor.kl...@gmail.com> wrote: >>> >>> >>> >>> Test methods, >> >> >> Yeah, I tho

Re: [concurrency-interest] We need to add blocking methods to CompletionStage!

Seems legit -- Cheers, √ On Sep 26, 2016 23:29, "Attila Szegedi" <szege...@gmail.com> wrote: > Not at all, you could just have a call to cancel() block until the future > completes. > > *ducks* > > Attila. > > > On 25 Sep 2016, at 16:34,

Re: We need to add blocking methods to CompletionStage!

2, 2016 at 7:51 PM, James Roper <ja...@lightbend.com> wrote: > >> For example, we often cache futures and return them from a libraries API, >> if a client could cancel a future, that would break everything else that >> received that future. > > > On Fri, Sep 23, 201

Re: We need to add blocking methods to CompletionStage!

On Sun, Sep 25, 2016 at 12:34 PM, Viktor Klang <viktor.kl...@gmail.com> wrote: > > > On Sat, Sep 24, 2016 at 10:41 PM, Martin Buchholz <marti...@google.com> > wrote: > >> No one is suggesting we add cancel to CompletionStage - I agree that >> would break

Re: We need to add blocking methods to CompletionStage!

On Sun, Sep 25, 2016 at 11:49 PM, Martin Buchholz <marti...@google.com> wrote: > > > On Fri, Sep 23, 2016 at 2:24 PM, Viktor Klang <viktor.kl...@gmail.com> > wrote: > >> >> PS. As a sidenote, Martin, and in all friendliness, "actor puri

Re: [concurrency-interest] We need to add blocking methods to CompletionStage!

ancelled returns true. But, > for example if the future is already completed when cancel is called, then > cancel will return false and isCancelled will return false. > > > > On Sep 25, 2016 6:49 AM, "David Holmes" <davidchol...@aapt.net.au> wrote: > > I think

Re: [concurrency-interest] We need to add blocking methods to CompletionStage!

On Sun, Sep 25, 2016 at 10:01 PM, Martin Buchholz <marti...@google.com> wrote: > > > On Sun, Sep 25, 2016 at 7:34 AM, Viktor Klang <viktor.kl...@gmail.com> > wrote: > >> If that truely is the case then the only way of implementing a readonly >> Future

Re: [concurrency-interest] We need to add blocking methods to CompletionStage!

@aapt.net.au> wrote: > >> I think that was meant to read “After this method returns _*true*_, >> subsequent calls …” >> >> >> >> David >> >> >> >> *From:* Concurrency-interest [mailto:concurrency-interest-b >> oun...@cs.oswego.edu] *On

Re: We need to add blocking methods to CompletionStage!

Hi Martin, *Unsurprisingly*, I think it is a bad idea to pollute something which was created as a non-blocking superset intended to provide maximum utility with minimum of sharp edges. However, I think you have a point in that toCompletableFuture throwing UOE is rather unhelpful, and if some

Re: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal

While we are painting the bikeshed, what about `powerNap()` On Tue, Dec 1, 2015 at 1:16 PM, Vitaly Davidovich wrote: > Minor quibble, but why the "on" prefix in the name? Maybe just me, but > onXYX is typically used for event notification style APIs. > > Also, the "wait" part

Re: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal

+1 On Thu, Oct 8, 2015 at 6:35 PM, Paul Sandoz wrote: > > > On 8 Oct 2015, at 18:33, mark.reinh...@oracle.com wrote: > > > > 2015/10/8 7:56 -0700, d...@cs.oswego.edu: > ... > > class Thread { // > /** > * A hint to the platform that the