Why does this create an infinite loop?

(defn tfn [] (let [ch (chan)
                   f  (future (put! ch (doall (pmap inc (range 100)))))]
               (go (while true (let [ret   (<! ch)
                                     total (count ret)]
                                 (println "done")
                                 (println "total is" total)
                                 (println ret)
                                 (close! ch))))
               f))

After it reads from the channel, it closes it, my thinking is that a temporary channel is created and closed on each invocation of the function tfn but instead i get an infinite loop of printlns

the idea is that tfn is non-blocking but still prints some stuff when the future is done, then disposes of this temporary channel after reading and processing the single item put on the channel

@ajs there's no exit to this loop, while true will cause the loop to run forever

what happens to the (<! ch) after the channel is closed, is that why the while-true no longer blocks?

i mean, blocks the printlns

yes, it'll return null once the channel closes, so switch your while to a loop, recurn and when-some

i guess if I'm only putting one thing on the channel like in this case, there is no need for the while loop, just the let...

(loop []
   (when-some [val (<! ch)]
      ...printlns...
      (recur)))

and the when-some is kindof critical, when-let would exit the loop if you send a false value down the channel, when-some will stop the loop only on nils

getting rid of the while-true, then is the close! all that is needed for proper cleanup in this function?

yes, close! will mark the channel to eventually start returning nil values. Here's the critical part: core.async defaults to not losing data. This means that the nil won't be returned until all enqueued data inthe channel is taken.

that can trip people up at times, close! is more like (>! ch nil) than a instant operation

will that channel get garbage collected and logically no longer exist when I run this fun? suppose I run it many times, is there anything sticking around that is not cleaned up by this simple close! operation?

Right so channels are GC'd once nothing is using them. Go blocks are turned into callbacks that are attached to channels.

remember that I'm only putting a single item on the channel, and reading it, then closing

i don't have to explicitly read that nil or anything from the close! ?

So most of the time, what's keeping a channel from being GC'd is that a thread is running and isholding a reference to the channel

right, you don't even have to close for the channel to be GC'd

i see, when the future is done running, no reference is held for the channel, is that what you mean?

as in, the future that is explicitly in my function

Well it's not even "when it's done running" if the only reference to the channel is a go block that has a pending take. Then nothing else can be holding on to the channel. So the channel will be GC'd and with it the go block that is waiting for a take.

So blocks and channels will never "go away" when you don't expect, but it's quite possible for chains of channels to deadlock and then be GC'd. But you'd never know, because there'd be no references to that chain in the system.

lots of magic there.

incidentally, i was thinking of you today @tbaldridge because i am playing around with fn-fx. would it be risky to adopt it for a big project? i'm at a point where I'm having to slap a gui on something and setting up a websocket server in my app for a web front end is not exciting, and swing/seesaw just look like the 1990s.

It's not as polished as seesaw, but give it a try.

I just added a dep in leiningen for [org.clojure/core.async "0.4.474"] and when I added a require for that into one of my project namespaces, I get an java.lang.ClassNotFoundException: clojure.core.async.Mutex error when attempting to launch my repl. any ideas?

it happens even without the require

Is there a stack trace? Who’s loading it?

That class doesn’t exist anymore in 0.4.474 (it did use to exist but wasn’t being used)

1m I’ll get a stack trace

as best as I can tell, this is, env/dev/user.clj (the user ns, home for the repl), loading myapp.config, loading myapp.fixtures, loading pedestal, and it’s happening in pedeestal somewhere

hm

I’m running pedestal 0.5.3

are you aot compiling?

I’m running lein repl

I would clear out any possibly stale stuff in target/ and maybe run lein pedantic

you are aot compiling, you have a :main or :aot key or whatever it is set in project.clj

lein is attempting to aot compile your project before starting that repl, which is where that error is happening

aha, no it’s not aot compiling

so you likely have stale class files in target/

oh, sorry, right I misread the stacktrace, but check lein pedantic or whatever it is called these days to make sure you are getting the version of core.async you think

bah, yeah I think clean did it

unfortunately our test suite requires being ran against a compiled^H^H^H^H^H^H^H^H^H jar

😠

jars aren't compiled

well

they are zip files

you can run clojure from a jar without aot compiling

and there are techniques to limit the amount that gets aot compiled

https://github.com/hiredman/clojure-site/blob/df56aef005d5d867213a51c2d3bbec5a86b0acad/content/guides/running_a_clojure_program.adoc

sorry, dealing with an in-office conversation as well

what I meant to say was that it requires being ran against an uberjar from /target from some other docker

which, really, I’ve considered setting up two copies of the repo

and sometimes my script for running the tests doesn’t clean up properly, and it doesn’t tell me, and I always forget about that

it’s working now, thanks