Clojure Q&A - Recent activity in Refs, agents, atoms

Commented: Why vswap is a macro instead of function like swap?

Tue, 06 May 2025 04:56:15 +0000

with direct-linking enabled during compilation function will be called directly instead of resolving through a var , correct? (i am talking about direct function call , not passing function in HOF)

Commented: Why does `await` fire off an `agent`'s watch?

Sat, 25 Jan 2025 11:01:52 +0000

sorry, overloaded term. In my use case specifically the agent sends a value to another agent. You can't await inside the agent action, and you can't await the first agent to wait for the chain to execute. So there is no way to wait for the second agent without explicitly tracking everything from the main thread.

Edited: Is there a polished version of auto-agents?

Thu, 26 Dec 2024 19:37:31 +0000

I was reading Clojure in Action and thinking about agents. It seems that by hooking up agents with watches, update functions, and some simple locks, you could create a “reactive" state management. So that when some value a is updated then all dependent state values update themselves automatically and in parallel on separate threads. While those values are updating you are free to change other state values that aren't in the same dependency graph

I wrote up a quick draft but then started to look around online (it felt like a bit too obvious of an extension to the agent model). I found some similar ideas back in ~2009 but the trail goes dry. Is there some reason this isn't used more widely? Or is this some modern library I'm missing?

There was a "cell" implementation by Stuart Sierra called auto-agents - though I can't find the code

https://groups.google.com/g/clojure/c/NY834N34QvA

I also found this complete implementation but it's also got no traction at all

https://github.com/apatil/lazy-agent

Has this crystallized into a library somewhere? I'm thinking of writing my own implementation but I wanted a sanity check. I'm concerned maybe this idea was dropped for some reasons I've not considered

(I'm aware there are things like Javelin, Odoyle and Missionary that can accomplish similar things.. but while they decouple code, they're way too complicated and some don't have a threading story)

This is a copy of my question on Reddit:
https://reddit.com/comments/1hklfyh/comment/m3gyyoq

Commented: Memory leak in seque via agents

Tue, 15 Oct 2024 20:11:24 +0000

This leak could also affect overtone's ability to GC the cycled functions in this helper once the returned fn is GC'ed: https://github.com/overtone/overtone/blob/535c9c50cb52aa275f3e2e7474842dbcfaa6eff5/src/overtone/algo/fn.clj#L27

Answer selected: Ref transactions causing deadlock at the REPL

Wed, 10 Jul 2024 15:49:14 +0000

I assume both transactions are failing and retrying multiple times, and each retry takes a very long time until one of them happens to get the timing right to work or maxes out the retries.

You should never do blocking operations in your transactions.

Answer selected: What's an ideomatic way to manage state in a library?

Thu, 15 Feb 2024 13:57:30 +0000

Yes, make state explicit, passed as arguments. Don't use global state. Don't use dynamic vars either. Don't assume a specific state framework such as Integrant or Component.

This way consumers will have the most flexibility and simplicity.

Edited: How to force a timeout?

Mon, 18 Dec 2023 17:48:00 +0000

(defn tid []                                                        
  [(.getName (Thread/currentThread))                                                        
   (.getId (Thread/currentThread))])

   (defn atomize                                                   
  [f data]                                                                                  
  (let [atomix (atom [])                                                                    
        pool (Executors/newFixedThreadPool 12)                                              
        tasks (map                                                                          
               (fn [datum]                                                                  
                 (fn []                                                                     
                   (swap! atomix conj [(f datum) (tid)])))                                  
               data)]                                                                       
    (doseq [future (.invokeAll pool tasks)]                                                 
      (.get future  10 TimeUnit/MILLISECONDS ))                                             
    (.shutdown pool)                                                                        
    @atomix))




I can't figure out where to place a `sleep` to force a timeout.

Comment reshown: Somehow I have to loop after all

Wed, 22 Nov 2023 13:44:39 +0000

Thanks. I begin to see it clearly now. And i really didn‘t see the race condition.

Answered: How can I retrieve all older values of a PDS like atom/ref/agents ?

Mon, 28 Feb 2022 13:23:12 +0000

I will add to the earlier answer.

Clojure's reference types (atoms, ref, agents) are orthogonal to persistent data structures. They are used in conjunction with persistent data structures (e.g. the expectation is that immutable values will be contained in said reference types to enforce software transactional memory semantics and the like), but they aren't directly related. Reference types model an identity, e.g. some information that may vary over time where the successive values are related by some named thing.

Persistent data structures let you maintain references to an original value, and create new values that represent semantic "modifications" to the original (e.g. associate a new key in map, change the value at index 3 in a vector, conj an item to a set, etc.). Since this is accomplished via typically hash array mapped trie variants (and in the case of sorted collections, red/black balanced binary trees, or cons cells in the case of seqs), the efficiency gains come from sharing as much structure as possible between the derived "new" value and the old. So some form of path copying scheme exists where only a minimal subset of the old tree is actually necessary to copy and then safely modify the copied subtree when creating the new structure; everything else is referenced.

Aside from performance (minimal path copying in tries makes for surprisingly efficient vectors and maps), this enables writing in the pure functional style that clojure defaults to. We can write complicated, useful programs without basing them on mutation and side effects. Since our fundamental collections are persistent, then reasoning about the basic operations is trivial (pervasively so!): I always know that assoc, dissoc, conj ,disj, etc. will not modify the input and will return either an equivalent value or a different value (as opposed to a mutable container where value/equality semantics are ambiguous). Information flow through a program written in this style is distilled to functions, input, and output where information can only really flow one direction (since inputs are never modified).

The other upside of this is that you have the ability to retain cheap (memory efficient) copies of older versions. This is not intrinsic and has nothing to do with reference types directly, but we can use a reference type (like an atom) to implement some naive form of versioning:

(def versions (atom [[]]))
(defn current
  ([v] (peek @v))
  ([] (current versions)))
(defn update! [f & args]
  (let [newv (apply f (current) args)]
    (swap! versions conj newv)
    newv))

(defn roll-back!
  ([v] (-> v (swap! #(if (seq (peek %)) (pop %) %)) peek))
  ([] (roll-back! versions)))

;; user=> (update! conj 2)
;; [2]
;; user=> (update! conj 3)
;; [2 3]
;; user=> (roll-back!)
;; [2]
;; user=> (roll-back!)
;; []

(let [original (current)
      v1 (update! conj 2)
      v2 (update! conj 3)
      v3 (update! conj 4)
      v4 (do (roll-back!) (roll-back!))]
  {:v1 v1
   :v2 v2
   :v3 v3
   :v4 v4})

;;{:v1 [2], :v2 [2 3], :v3 [2 3 4], :v4 [2]}

In the let demo, the references associated in the map for v1 v2 v3 and v4 are all different values, although there is structural sharing between them. They are all thread safe and can persist without affecting anything else (since they can't change). Assuming space isn't a concern, using this kind of scheme allows trivial "undo" at potentially complex application data levels. It is trivial to maintain everything in an app state, and retain a log of previous versions. Rewinding the application state is as simple as popping items off of the history. We don't need to delta diff or anything, or generate patches, since the shared structure is already taken care of for us.

If you stick with the persistent data structures to model your application data, then you effectively have the ability to snapshot the entire "world" at whatever level of granularity you would like (if it makes senses).

Closed: calling realized? on a delay which is currently executing blocks the caller

Tue, 14 Sep 2021 21:30:54 +0000

If a delay is currently processing, calling realized? causes the caller to block until the delay has completed and then returns true.

The behaviour I would have expected is that it should return false, which is what happens with futures. After all, if you wanted to wait until it was completed, you would deref it.

(also there don't seem to be any tags or categories related to concurrent programming, but since delay is part of clojure.core, I assume this is the correct place to ask)

Answer selected: How to known all the actions of an agent have been executed?

Tue, 05 Jan 2021 07:53:30 +0000

await does exactly this:
(clojure.repl/doc await)
clojure.core/await ([& agents]) Blocks the current thread (indefinitely!) until all actions dispatched thus far, from this thread or agent, to the agent(s) have occurred. Will block on failed agents. Will never return if a failed agent is restarted with :clear-actions true or shutdown-agents was called.

To try it out:
(def a (agent 0)) (dotimes [_ 100] (send-off a (fn [x] (Thread/sleep 30) (inc x)))) (await a)
(Will block for a few seconds)

Answered: Where is volatile! officially documented?

Sat, 23 May 2020 23:36:32 +0000

Clojure’s use does build on Java’s volatiles so the name is intentional.

The only other place I can think of where it’s documented is in the release notes https://github.com/clojure/clojure/blob/master/changes.md#21-transducers

It’s considered kind of an advanced tool so it’s intentionally not front and center. Could probably be mentioned in the transducer docs as an impl tool.

Answered: atom watchers are not atomic with respect to reset!

Wed, 26 Jun 2019 12:00:00 +0000

Reference: https://clojure.atlassian.net/browse/CLJ-1770 (reported by ericnormand)

Answered: Tests for clojure.core/atom

Wed, 26 Jun 2019 12:00:00 +0000

Reference: https://clojure.atlassian.net/browse/CLJ-1915 (reported by claj)