Re: core.async top use cases

I've used agents to wrap thread-unsafe mutable Java objects with a defined life cycle, so that they could be used from multiple threads whilst respecting the life cycle. My particular case was server-side gRPC StreamObservers for long lived client connections. These are either usable, closed, o

Re: core.async top use cases

Yeah, I used to do that, but once core.async came out I started to desire the back pressure aspects of channels. I don't think I've used agents for logging since. You always run the risk of something backing up the queue of the agent and causing your thread to crash when it runs out of memory. On

Re: core.async top use cases

I always found it a bit ironic that my main use case for agents doesn't really at all make use of the "mutable ref" aspect of the agent, only the queue piece. I usually hold the name of the log file in the mutable ref to emphasize that the agent is "guarding" this particular log file, but I don't

Re: core.async top use cases

My primary use case for agents has always been when I want to coordinate multiple threads writing to a log file. The agent effectively serializes all the write requests with a minimum of fuss. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post t

Re: core.async top use cases

The other other special feature of agents is that the stm knows about them so it's a safe way to have a side effect occur in an stm transaction (all agent sends are delayed till the txn succeeds). I've found that to be pretty handy in advanced usage. -- You received this message because you ar

Re: core.async top use cases

Agents combine two things 1) a queue of functions, 2) mutable state. The key thing about agents is that they still respect Clojure's concept of "instant deref". That is to say, you can always deref an agent even if the queue is backlogged. This is one of the key differences between agents and actor

Re: core.async top use cases

>> When using clojurescript, adding async really increases the load time. That's one place where you might want to use agents when you can. But Clojurescript doesn't support agents. On Thu, Oct 13, 2016 at 7:16 PM, William la Forge wrote: > On Thursday, October 13, 2016 at 3:38:16 PM UTC-4, lar

Re: core.async top use cases

On Thursday, October 13, 2016 at 3:38:16 PM UTC-4, larry google groups wrote: > > So when to use agents? I've looked through Clojure repos on Github, > looking for uses of agents, and I found very few. (I was writing a blog > post about concurrency in Clojure, and I found that agents are among t

Re: core.async top use cases

> It is not just convenience. For example agents don't provide functionality like buffering, back pressure > and select aka alts. If you send an action to an agent you don't get to know when it's done or > to choose what to do if it is currently busy. So when to use agents? I've looked throu

Re: core.async top use cases

Fine grained control of parallelism is a superb aspect of core.async. Cassandra is a distributed database, often a query requires you resolve-on-read denormalised data partitioned multiple ways (semantically, by time, etc). You can think of it like a grid I guess. Lets say I have a query that I

Re: core.async top use cases

y > Sent:Wed, 21 Sep 2016 03:47:29 +0300 > To:Clojure > Subject:Re: core.async top use cases > > I'm no expert on this, but the Actor model and the CSP model seem to be > two different ways to model a concurrent system. Clojure supports them > both. Personally I find the CSP

Re: core.async top use cases

clojure supports the actor model. Sent from my mobile Original Message From:Beau Fabry Sent:Wed, 21 Sep 2016 03:47:29 +0300 To:Clojure Subject:Re: core.async top use cases >I'm no expert on this, but the Actor model and the CSP model seem to be two >different ways

Re: core.async top use cases

to further clarify? > > > Original Message > From:William la Forge > Sent:Tue, 20 Sep 2016 02:37:20 +0300 > To:Clojure > Subject:Re: core.async top use cases > > The really nice thing to me is that async handles side-effects while > agents do not. > > -- &g

Re: core.async top use cases

so. Care to further clarify? > > > Original Message > From:William la Forge > Sent:Tue, 20 Sep 2016 02:37:20 +0300 > To:Clojure > Subject:Re: core.async top use cases > > The really nice thing to me is that async handles side-effects while > agents do

Re: core.async top use cases

Thanks but I'm not entirely sure about this. I could use agents for side effects too, or at least I thought so. Care to further clarify? Original Message From:William la Forge Sent:Tue, 20 Sep 2016 02:37:20 +0300 To:Clojure Subject:Re: core.async top use cases >Th

Re: core.async top use cases

On Sat, Sep 17, 2016 at 11:37:38PM -0700, Matan Safriel wrote: > Hi, > > It's very easy to see how core.async solves callback hell for front-end > development with clojurescript. > In what use cases would you use it for server-side? we already have > non-blocking IO from Java, and we have clojur

Re: core.async top use cases

The really nice thing to me is that async handles side-effects while agents do not. -- 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

Re: core.async top use cases

Right! Original Message From:Leon Grapenthin Sent:Mon, 19 Sep 2016 20:19:55 +0300 To:Clojure Subject:Re: core.async top use cases >It is not just convenience. For example agents don't provide functionality >like buffering, backpressure and select aka alts. If

Re: core.async top use cases

It is not just convenience. For example agents don't provide functionality like buffering, backpressure and select aka alts. If you send an action to an agent you don't get to know when it's done or to choose what to do if it is currently busy. On Monday, September 19, 2016 at 11:49:13 AM UTC+

Re: core.async top use cases

Thanks, and I put the blog post on my reading list. Although I can't avoid thinking that we already have asynchronous idioms in the core language itself, like agents. I think the crux for server-side is more about the convenient piping, rather than the mere asynchronism itself, but I might be wrong

Re: core.async top use cases

Pushing asynchrony further into the stack is useful for reliability and fault tolerance. We can also use it as a basis for Complex Event Processing using time series windows. I wrote up a few examples in my blog

Re: core.async top use cases

http://aleph.io/aleph/literate.html "Alternately, we can use a core.async goroutine to create our response, and convert the channel it returns using manifold.deferred/->source, and then take the first message from it. This is entirely equivalent to the p

core.async top use cases

Hi, It's very easy to see how core.async solves callback hell for front-end development with clojurescript. In what use cases would you use it for server-side? we already have non-blocking IO from Java, and we have clojure agents. So what's a bunch of salient use cases? Are there prominent cloj