how exactly does the "ordering" part of agents work?

Do they each have one queue? Is it like locking?

only one thing is working on an agents state at a time right?

@emccue that is my understanding, yes. Agents single-thread all their work.

> The actions of all Agents get interleaved amongst threads in a thread pool. At any point in time, at most one action for each Agent is being executed. Actions dispatched to an agent from another single agent or thread will occur in the order they were sent, potentially interleaved with actions dispatched to the same agent from other sources. send should be used for actions that are CPU limited, while send-off is appropriate for actions that may block on IO.

I'm not 100% sure. But my understanding is that each agent gets it's own queue of actions. And so each agent has one action at a time being executed on either the cpu thread pool or the IO thread pool

But multiple agents run in parallel. But each single agent will not.

No locking is involved

That means they're good for parallelizing independent sets of work.

Like say you needed to do "A then B then C or D". This would be your set of work. And could be handled by one agent queuing 3 actions to it in order.

But if you only had one such set of work to do at a time. You could just do it synchronously by just composing the three actions one into the other

Agents come in handy if you have many such set of work. Say you needed to process 100 records. And for each record, you need to do "A then B then C or D". Then you could create 100 agents, and send the 3 actions to each of them. Then await them all.

Well... I say that, but the thing is, even for such a use case, you can as easily just spawn futures.

I think with agents, it's best to use them for managing long lasting state with dynamic actions (like user provided). For example, they'd be great for a text editor, where each buffer is an agent.

And each modification to a buffer is an action queued on the agent.

Or say you had a game server. Each active game can be an agent. So say you have many games running, each one is an agent. And player actions are sent to their appropriate agents to be executed asynchronously. With the main thread just dispatching actions.

Hi folks, I think I have made the right choice here, looking for reactions. I have been working toward releasing rewrite-cljc, which will be a maintained merge of rewrite-cljs and rewrite-clj. Ideally rewrite-cljc work would have simply been merged into the current rewrite-clj repo, but that did not work out, so rewrite-cljc will have different maven coordinates than rewrite-clj, most likely clj-commons/rewrite-cljc. Because I was thinking of rewrite-cljc as a drop-in replacement for rewrite-clj and rewrite-cljs, it currently reuses the rewrite-clj.* namespace. After some hemming and hawing and discussions with Clojure buddies (thanks @borkdude and @sogaiu), I have reconsidered: rewrite-cljc will move to its own rewrite-cljc namespace. The reasoning: having to rename :requires to rewrite-cljc in one's project to upgrade to rewrite-cljc is much less of a burden than the burden of the confusion of introducing colliding namespaces into the community. Colliding namespaces would likely first confuse, then require exclusions - a deps.edn example:

{olical/depot {:mvn/version "1.8.4" :exclusions [rewrite-clj/rewrite-clj]}}

@lee what you propose makes sense to me 👍

thanks @danielcompton!

@didibus my current use case is a distributed board game w/ some AI players

So it feels like a decent fit