Future, akka-stream, scalaz-stream
-
- いいね！0
Lgd. Viktor Klang
@viktorklang
@djspiewak "dead simple" with Futures. Enqueue promises when empty and dequeue is called, enqueue into a Vector otherwise. Guard with CAS.
2014-09-17 08:10:25
Daniel Spiewak
@djspiewak
@viktorklang A related way of looking at this is asking the following: can you write flatMap without taking an executor?
2014-09-20 01:54:06
Daniel Spiewak
@djspiewak
@viktorklang Though, the flatMap one is perhaps a poor choice since you could in theory get the executor from either composite future.
2014-09-20 01:54:53
Lgd. Viktor Klang
@viktorklang
@djspiewak Isomorphic to Future.successful(()).map(_ => println("uh?")). See: val p = Promise(()) val f = p.future.map(_ => println("uh?"))
2014-09-20 01:57:47
Lgd. Viktor Klang
@viktorklang
@djspiewak What thread of execution will evaluate the function you pass into it?
2014-09-20 01:58:25
Daniel Spiewak
@djspiewak
@viktorklang Yes, but the point is that I have a future which is actually *running* and saving the result for me.
2014-09-20 01:58:38
Daniel Spiewak
@djspiewak
@viktorklang I want a function (=> A ) => Future[A] which doesn’t evaluate the thunk if I discard the future.
2014-09-20 01:59:33
Lgd. Viktor Klang
@viktorklang
@djspiewak The Future is not running it for you, the ExecutionContext you provided will.
2014-09-20 01:59:55
Daniel Spiewak
@djspiewak
@viktorklang That’s the thing: Future has to answer that question because it runs eagerly. Task doesn’t have that problem.
2014-09-20 02:00:07
Daniel Spiewak
@djspiewak
@viktorklang Ok, so future delegates to a scheduler. It’s still the same thing from my perspective: the computation is running
2014-09-20 02:00:48
Lgd. Viktor Klang
@viktorklang
@djspiewak That's doable. When do you wnat it evaluated?
2014-09-20 02:01:31
Daniel Spiewak
@djspiewak
@viktorklang Task solves this problem by describing the computation lazily and choosing a thread pool at some later point.
2014-09-20 02:01:40
Daniel Spiewak
@djspiewak
@viktorklang When it is required to be evaluated by a subsequent future or by hitting the end of the world and calling get.
2014-09-20 02:02:15
Lgd. Viktor Klang
@viktorklang
@djspiewak No, you as the provider of the ExecutionContext is in full control over when to run things.
2014-09-20 02:02:21
Daniel Spiewak
@djspiewak
@viktorklang Or more usefully, someone saying to run said future asynchronously and giving a callback.
2014-09-20 02:02:41
Daniel Spiewak
@djspiewak
@viktorklang So I can give an execution context which runs this lazily and doesn’t memoize results?
2014-09-20 02:03:11
Lgd. Viktor Klang
@viktorklang
@djspiewak So lets shorten down that to: When I say so? Since you are in full control of the EC, it is up to you when you want it to run.
2014-09-20 02:03:27
Lgd. Viktor Klang
@viktorklang
@djspiewak Think of it like this, the ExecutionContext is a (possibly concurrent) interpreter that you are associating to different steps.
2014-09-20 02:04:14
Daniel Spiewak
@djspiewak
@viktorklang So how would I implement such a lazy, non-memoizing EC?
2014-09-20 02:04:43
Lgd. Viktor Klang
@viktorklang
@djspiewak It's lazy by default, since it cannot evaluate until dependent data is available. You can start and stop the execution of the EC.
2014-09-20 02:06:48
Lgd. Viktor Klang
@viktorklang
@djspiewak See here for an example of a suspendable and resumable EC: github.com/akka/akka/blob…
2014-09-20 02:07:24
Daniel Spiewak
@djspiewak
@viktorklang Hmm, what I want is to be able to implement this on top of Future: gist.github.com/djspiewak/4436…
2014-09-20 02:11:58
Daniel Spiewak
@djspiewak
@viktorklang (note that running run or runAsync multiple times results in re-running the computation)
2014-09-20 02:12:13
Daniel Spiewak
@djspiewak
@viktorklang Basically, I want to be able to describe the way my computation composes before *any part of it* is run, and maybe recompose.
2014-09-20 02:12:49