for this sort of logic, I use core.async go blocks containing a call to
core.async/thread, doing some other operation asynchronously with the value
in the channel it returns
(go
(let [result (<! (thread (do-something))]
(do-something-else result)))
this is non-blocking and runs in core.async's thread pool and state
machine, and when I have multiple conditions to coordinate on, the kind of
code core.async lets me write is much more readable compared to callback
nesting
I also have my own version of thread which attempts support cancellation
while also handling the attached channel properly, but I haven't done the
work to vet it as generally usable
https://gist.github.com/noisesmith/02ee2ee5dcb8c0290bd8004c4c4d36aa
On Wed, Aug 2, 2017 at 2:09 PM <lawrence.krub...@gmail.com> wrote:
> I stumbled across this old post by Tomasz Nurkiewicz:
>
> http://www.nurkiewicz.com/2013/03/promises-and-futures-in-clojure.html
>
> He writes:
>
> "And here is where the greatest disappointment arrives: neither future
> <http://clojuredocs.org/clojure_core/clojure.core/future> nor promise
> <http://clojuredocs.org/clojure_core/clojure.core/promise> in Clojure
> supports listening for completion/failure asynchronously. The API is pretty
> much equivalent to very limited java.util.concurrent.Future<T>
> <http://nurkiewicz.blogspot.com/2013/02/javautilconcurrentfuture-basics.html>.
> We can create future, cancel it
> <http://clojuredocs.org/clojure_core/clojure.core/future-cancel>, check
> whether it is realized? (resolved)
> <http://clojuredocs.org/clojure_core/clojure.core/realized_q> and block
> waiting for a value. Just like Future<T> in Java, as a matter of fact the
> result of future function even implements java.util.concurrent.Future<T>.
> As much as I love Clojure concurrency primitives like STM and agents,
> futures feel a bit underdeveloped. Lack of event-driven, asynchronous
> callbacks that are invoked whenever futures completes (notice that
> add-watch <http://clojuredocs.org/clojure_core/clojure.core/add-watch> doesn't
> work futures - and is still in alpha) greatly reduces the usefulness of a
> future object. "
>
> That was written in 2013. I think since then the community has found other
> ways to achieve the same goals? I'm curious what patterns have become
> common? Would it be correct to say that for most of the use cases where one
> would otherwise want a notification of completion on a Future, people
> nowadays instead use something like core.async or a library such as
> Manifold?
>
>
>
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
