Re: ref strange behavior

I wasn't satisfied with the various answers to both this thread and the StackOverflow question, so I spent a bit more time digging; it turns out this was a bug in the range implementation that was fixed in 1.9.0-alpha11. I've added a bit more details on StackOverflow [1]; the full story is on the

Re: ref strange behavior

On Tue, Aug 23, 2016 at 10:59 AM Sergei Koledov wrote: > Thank you! I know about Java's thread pools, but I want to do my job in > clojure-idiomatic way and possibly less using java interop. > > I think many of the use-cases for refs/agents are supplanted by core.async. In

Re: ref strange behavior

Thank you! I know about Java's thread pools, but I want to do my job in clojure-idiomatic way and possibly less using java interop. вторник, 23 августа 2016 г., 20:21:23 UTC+7 пользователь tbc++ написал: > > This really seems like a good use case for Java's Executors: >

Re: ref strange behavior

Thank you very much! I suspected that I using the agents in wrong way. I ran your code and it worked great. Also I little changed your example to a worker keep only the last task and run it on very large number of tasks (I had problem only on huge collections): (def tasks (ref (into [] (range

Re: ref strange behavior

The lazy sequence works with the code I provided as well. On Tuesday, August 23, 2016 at 9:29:08 AM UTC-4, Sergei Koledov wrote: > > Yes, you are absolutely right. After i modify the code as you advised, it > worked correctly. Thank you very much! > Does it mean that is necessary to avoid the

Re: ref strange behavior

Here is working example code demonstrating how you might do this without agents: (in-ns 'user) (def tasks (ref (into clojure.lang.PersistentQueue/EMPTY (range 1 1000 (defn get-task [tasks] (dosync (let [task (first @tasks)] (alter tasks pop) task))) (defn worker-loop

Re: ref strange behavior

Yes, you are absolutely right. After i modify the code as you advised, it worked correctly. Thank you very much! Does it mean that is necessary to avoid the use of lazy data structures within the STM? вторник, 23 августа 2016 г., 19:57:58 UTC+7 пользователь hitesh написал: > > Taking a quick

Re: ref strange behavior

This really seems like a good use case for Java's Executors: https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/Executors.html#newFixedThreadPool(int) You can specify the number of worker threads, then enqueue runnable jobs. But wait! There's more! Clojure functions implement

Re: ref strange behavior

I haven't run your code yet, but it's bad form to use Clojure's reference types inside other reference types. They should store persistent data structures to really make any sense in a concurrent context. On Tuesday, August 23, 2016 at 8:22:00 AM UTC-4, Sergei Koledov wrote: > > Hello, > > I

Re: ref strange behavior

Taking a quick look at this, I *think* the problem crops up in your tasks being a lazy sequence. Modify this (def tasks (ref (range 1 1000))) to this (def tasks (ref (doall (range 1 1000 Running that with your large endpoint was taking a lot of time, so I'd suggest running it

ref strange behavior

Hello, I had a problem when I run the following code: (defn get-task [tasks] (dosync (let [task (first @tasks)] (alter tasks rest) task))) (defn worker [& {:keys [tasks]}] (agent {:tasks tasks})) (defn worker-loop [{:keys [tasks] :as state}] (loop [last-task nil]