Fork me on GitHub
#clojure-italy
<
2022-02-14
>
Andrea Imparato10:02:55

buongiornissimo! domandine core.async per voi mega esperti: 1. ha senso usare atoms nelle callbacks degli agents? Io direi di no perche’ l’agent viene eseguito su un thread separato, ma non si sa mai 🙂 2. ho fatto qualche prova usando agents per simulare un po’ di scritture I/O eseguite da un agente e mi sembra che non ci sia questa grande differenza tra farlo sequenzialmente e farlo con un agente (che poi alla fine eseque sequenzialmente anche lui alla fine… sara’ per questo?). Forse ha senso solo quando c’e’ piu’ di un agente che gira o quando viene tutto eseguito su thread diversi dal main? Illuminatemi un po’ 🙂

reborg11:02:18

E' tanto che non lavoro con core.async, e la mia esperienza e' sempre stata superficiale. Ma nella tua domanda c'e' qualcosa che non capisco, che e' perche' parli di agenti. Non me lo aspetto.

reborg11:02:23

Sembra che stai chiamando core.async gli atoms/agents in clojure, che sono concurrency constructs che non hanno a che fare con core.async. Quindi volevo essere sicuro.

Andrea Imparato11:02:05

si, errore mio, gli agents non fanno parte di async. mi riferisco agli agent in core

reborg11:02:25

ok, provo a rispondere a breve

reborg10:02:08

> 1. ha senso usare atoms nelle callbacks degli agents? Cos'e' la definizione di callback? Stai usando https://clojuredocs.org/clojure.core/add-watch? Un Agent contiene state come un atom, quindi non sono sicuro del significato di callback in questo contesto. > 2. ho fatto qualche prova usando agents per simulare un po’ di scritture I/O eseguite da un agente e mi sembra che non ci sia questa grande differenza tra farlo sequenzialmente e farlo con un agente Anche qui ho bisogno di una definizione di "farlo sequenzialmente". Un esempio tipico di utilizzo di agents e' fare logging. La differenza tra farlo con un agent o senza e' che la tua app rimane appesa in attesa di scrivere oppure no.

Andrea Imparato11:02:50

> Cos’e’ la definizione di callback? E’ la funzione che l’agente va ad eseguire. E mi sono sbagliato a chiamarla callback in effetti

Andrea Imparato11:02:36

un esempio di cosa intendo (def a (agent 0)) (def b (atom 0)) (for [i (range 10)] (send a (fn [old-value new-value] (swap! b inc))) (println @b)

Andrea Imparato11:02:42

> Anche qui ho bisogno di una definizione di “farlo sequenzialmente” Sequenzialmente intendo che l’agente eseguira’ le funzioni che gli ho mandato in send in sequenza, non in parallelo, e dato che l’app non rimane in attesa per me e’ come se fossero eseguite async, quindi mi aspetto che se faccio molto i/o dovrei usare agenti cosi’ possono farlo in modo asincrono. Quindi la domanda vera e’: dato che gli agenti servono per gestire stati dove praticamente applico una funzione ad un vecchio valore e ne ottengo uno nuovo in modo sequenziale ed asincrono, posso usarli per fare i/o? Per dare un po di contesto, leggendo online ho visto che la gente sconsiglia vivamente di fare io in go threads per via della thread pool ed usare veri thread invece ma poi mi sono chiesto, non sarebbe meglio usare direttamente gli agenti per fare i/o?

reborg11:02:22

Per quanto riguarda l'esempio, perche' non usi agents invece di un atom esterno?

(def a (agent 0))
(dotimes [i 10] (send a inc))
(await a)
@a
;; 10
Dunque si, puoi fare IO con agents poi dipende dalla quantita' di IO e quanto l'agente rimane appeso in IO. La differenza con core.async sarebbe che i scala meglio anche con blocking IO, ma non e' comunque una soluzione magica (vedi https://martintrojer.github.io/clojure/2013/07/07/coreasync-and-blocking-io)

Andrea Imparato11:02:14

Si un atom sarebbe quello da usare di sicuro, mi chiedevo solo cosa succede se faccio swap dentro un agent? Funziona come se fossi nel main thread oppure no?

reborg11:02:18

No, sei nell'agent thread

👍 1
Andrea Imparato11:02:47

Ok quindi un agent va bene ma se c’è troppo lavoro meglio usare async thread che così con i channel posso controllare il throughput ma ovviamente c’è il costo della coordinazione dei thread

reborg11:02:04

beh anche il fatto che tu debba usare callback o meno e' importante per decidere. Se e' "fire and forget" (modello logging) allora puo' chiederti cosa e' meglio. Ma se c'e' coordinamento e devi chiamare qualcos'altro con callbacks forse no.

Andrea Imparato11:02:29

Ottimo grazie mille @U054W022G mi sei sempre utile per capire cose :D

👍 1