Curious to why KeptPromise needs an ExecutionContext

[andy]

Just a curiosity. Why do Promise.successful and Promise.failed, both backed by KeptPromise, need an execution context? Since they aren't actually doing anything on another thread the execution context seems superfluous. Is it for composability with other futures? I looked into the code for KeptPromise and didn't see how the execution context was used.

Thanks,

Andy  

[√iktor Ҡlang]

On Fri, May 18, 2012 at 12:07 AM, andy <andrew....@gmail.com> wrote:

Just a curiosity. Why do Promise.successful and Promise.failed, both backed by KeptPromise, need an execution context? Since they aren't actually doing anything on another thread the execution context seems superfluous. Is it for composability with other futures? I looked into the code for KeptPromise and didn't see how the execution context was used.

All Futures have to be associated with an ExecutionContext so they know where to submit their callbacks for execution.

Cheers,

√

 

Thanks,

Andy  

--
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To view this discussion on the web visit https://groups.google.com/d/msg/akka-user/-/KelOEupyVQ0J.
To post to this group, send email to akka...@googlegroups.com.
To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.

--
Viktor Klang

Akka Tech Lead

Typesafe - The software stack for applications that scale

Twitter: @viktorklang

[andy]

Word. Makes sense.

so in,

Promise.success("Hello").map( _ + " World" ) 

the map callback would execute using the execution context.

Thanks,

Andy

On Thursday, May 17, 2012 4:31:16 PM UTC-7, √ wrote:

On Fri, May 18, 2012 at 12:07 AM, andy <andrew....@gmail.com> wrote:

Just a curiosity. Why do Promise.successful and Promise.failed, both backed by KeptPromise, need an execution context? Since they aren't actually doing anything on another thread the execution context seems superfluous. Is it for composability with other futures? I looked into the code for KeptPromise and didn't see how the execution context was used.

All Futures have to be associated with an ExecutionContext so they know where to submit their callbacks for execution.

Cheers,

√

 

Thanks,

Andy  

--
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To view this discussion on the web visit https://groups.google.com/d/msg/akka-user/-/KelOEupyVQ0J.
To post to this group, send email to akka...@googlegroups.com.

To unsubscribe from this group, send email to akka-user+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.

[√iktor Ҡlang]

On Fri, May 18, 2012 at 3:03 AM, andy <andrew....@gmail.com> wrote:

Word. Makes sense.

so in,

Promise.success("Hello").map( _ + " World" ) 

the map callback would execute using the execution context.

Yes, exactly.

We're having a discussion for SIP-14 now whether the EC should go on every method that uses callbacks or only on the "producer".

Cheers,

√

 

To view this discussion on the web visit https://groups.google.com/d/msg/akka-user/-/wEkQ1OUkp48J.

To post to this group, send email to akka...@googlegroups.com.

To unsubscribe from this group, send email to akka-user+...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.

[andy]

Initially in my services that returned futures I would pass in an actor system or execution context into the class constructor. Lately I have been switching so that methods returning futures have a curried implicit execution context in their definitions. I feel it is easier to wire up my app this way and allows me greater control over how service calls compose with the underlaying threading model.

2 cents

p.s. I love akka futures

[√iktor Ҡlang]

On Fri, May 18, 2012 at 3:33 AM, andy <andrew....@gmail.com> wrote:

Initially in my services that returned futures I would pass in an actor system or execution context into the class constructor. Lately I have been switching so that methods returning futures have a curried implicit execution context in their definitions. I feel it is easier to wire up my app this way and allows me greater control over how service calls compose with the underlaying threading model.

Yup, and also it lets the consumers of Ftuures to be EC-unaware.

 

2 cents

p.s. I love akka futures

Glad to hear that! A lot of great work has gone into them, Derek Williams was the guy who took the first step into making them awesome.

Cheers,

√

 

To view this discussion on the web visit https://groups.google.com/d/msg/akka-user/-/_73tqHEgaSwJ.

To post to this group, send email to akka...@googlegroups.com.

To unsubscribe from this group, send email to akka-user+...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.