Using go/<! like C#'s async/await

[Martin Raison]

go blocks tend to spread in Clojure programs just like async/await in C#/Hack/Python, etc. The problem is that they aren't cheap.

I was curious to know what you guys think of the following workaround: http://blog.martinraison.com/clojure/2015/07/27/clojure-core-async-go-blocks-everywhere.html

(TL;DR: use "go" only in the few functions that do some actual work, in all other places use an alternate version - called "async" in the article - that doesn't use the dispatcher and doesn't create a chan. The only thing "async" does is handling the state machine stuff, so that <!, alt!, etc work as expected.)

Does that seem reasonable or do you see a better way to do this?

[Thomas Heller]

Hey,

I made a similar suggestion (minus the ThreadLocal) a few weeks ago, although for slightly different reasons. [1]

It should be noted that your async macro does in fact use the dispatcher just like a normal go would, the only difference is that it will start executing immediately in the current thread until the first "pause" instead of dispatching. After the "pause" the dispatcher will run it though which is not guaranteed to be the same thread. Therefore I'm not actually sure a ThreadLocal will work. Did you test that you get the actual correct result?

Your benchmark is also not very useful, you are basically just measuring the frameworks overhead which is tiny to what it provides. In actual programs most of the time will not be spent in core.async internals, at least not from what I have observed so far. go blocks are actually pretty cheap.

YMMV,

/thomas

[1] http://dev.clojure.org/jira/browse/ASYNC-131

[Martin Raison]

Hey Thomas,

Thanks for the great feedback! A few clarifications below.

 

It should be noted that your async macro does in fact use the dispatcher just like a normal go would, the only difference is that it will start executing immediately in the current thread until the first "pause" instead of dispatching. After the "pause" the dispatcher will run it though which is not guaranteed to be the same thread.

I agree that the dispatcher will eventually be used, but the idea is that if your code is deeply nested, this will only happen at the deepest level (when an actual go block is used). So the dispatcher will only be run there, instead of running for every single wrapping function call. The idea is for the codebase to look like this (across multiple functions):

(async ... (<! (async ... (<! (async ... (<! (async ... (<! (async ... (<! (go <long-running stuff, run in a different thread>)))))))))))

Here the dispatcher is only run once, instead of 6 times. All the "glue code" is run in the calling thread.

 

Therefore I'm not actually sure a ThreadLocal will work. Did you test that you get the actual correct result?

I do get the correct result, although your concern is valid. I think it works because the generated state machine calls ioc/return-chan in the curent thread. If part of the computation has been dispatched to an other thread, then the result of that dispatched computation will be brought back into the current thread with an actual channel before being fed to ioc/return-chan. I would love to know if there are situations where return-chan would be called directly from another thread, since I haven't observed that so far and I'm not familiar enough with the state machine internals.

 

Your benchmark is also not very useful, you are basically just measuring the frameworks overhead which is tiny to what it provides. In actual programs most of the time will not be spent in core.async internals, at least not from what I have observed so far. go blocks are actually pretty cheap.

Measuring the framework overhead was in fact my intention, but I agree it would be useful to know if the core.async overhead can actually be significant in a real-world application. Typically an IO-bound application passing lots of requests to other servers and doing very light transformation on the results.

 

[Timothy Baldridge]

My advice is to treat channel ops (<! and >!) as IO, which they are. In functional programming we try to stay away from doing IO deep down inside a call stack. So don't do that. Instead use async/pipeline functions and channel transducers to create pipelines and flow the data through them. 

A sort of anti-pattern I see a lot is creating a lot of one-shot channels and go blocks inside every function. The problem, as you see is that this creates a lot of garbage. A much more efficient plan is to stop using core.async as a RPC-like system, and start using it more like a dataflow language: Identity data sources and sinks, and then transform and flow the data between them via core.async. 

It's interesting to note that core.async started as something that looked a lot like C#'s Async/Await, but that was dropped in favor of CSP pretty quickly. So there's reasons why the language isn't optimized for this sort of programming style. 

Timothy

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@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+u...@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+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

“One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.”
(Robert Firth)

[Martin Raison]

Fair point, thanks a lot for the insight. Any pointers to a significant data-flow oriented clojure codebase would be awesome, because that's not something I see a lot in the wild, and I'm still trying to wrap my head around how to implement this on a very complex system.