Clojurians Log v2

you want repeatedly

@kwladyka I think since core.async can easily lock up its threads, it distracted us from the fact that it could be your job that do instead

I'd say, you probably want to add some form of timeout to your jobs then

(alt!
  (timeout 10000)
  :timed-out
  (thread
    (try
      (job)
      :success
      (catch Throwable ex
        :error)))
  ([result] result))))

And log something on timeout

Could be useful in the future, if any other job happens to go on forever, then you'll know

Question to others: Would there be a way to get the thread created by core.async thread? So that we could interup it?

yes, I fixed did

pass a channel in to your core.async thread, put the java.lang.Thread/currentThread on to it ?

you should have a way to allow a clean exit of that Thread

instead

listening on an poison-pill kind of chan for this from inside your async/thread is a way to do this. could be a simple promise-chan that you close! to signal exit and then listen to via alts inside the thread

but if your thread is blocking on some i/o, or other monitor, you may need to interrupt it, if it's not going to timeout and clean itself up ?

@didibus I don’t think this is the right solution, because thread which stuck will consume memory forever. After a while this can make OOM. Unless I am wrong and the thread will be killed?

I would prefer timeout on thread instead

But not sure how this should be done. I didn’t have time to go deeper into it.

one thing to think about when exposing the thread is that once the job is done, the thread can be assigned to another job.

you may interrupt that other job accidentally

oh, yeah, so if you are going to interrupt you really need to be sure that you are interrupting the thing you intend to interrupt, and not the next thing that thread is being re-used for

yes

not impossible, but surprisingly hard to get right

could be nicely wrapped in, say, an interruptable-thread fn which returns [result-chan safe-interrupt-fn]

that looks like a future

it does rather - which makes sense

If you’re wanting to interrupt stuff then it sounds like a blocking op, which you should not do in a go loop, so you can set those aside. Others threads that do channel work are not special to core.async, they’re just normal threads. If you want to create one and interrupt it, go for it.

I’m assuming you mean like http://Thread.interrupt(). If you mean something less formal, then channels are the best way to communicate information to processes

I’m seeing this error in TravisCI: Could not find artifact org.clojure:core.async:jar:1.0.567 in central (<https://maven-central.storage-download.googleapis.com/repos/central/data/>)

Not sure what’s going on there, probably related to the recent version bumps?

if that's a mirror, could be lagging central (although that's quite a lag)

central: https://repo1.maven.org/maven2/org/clojure/core.async/1.0.567/

I would expect to find core.async jar in that mirror at https://maven-central.storage-download.googleapis.com/repos/central/data/org/clojure/core.async/1.0.567/core.async-1.0.567.jar

but it isn't there

Yeah that’s odd

I will raise an issue with Travis

it doesn't have the version before that either (0.7.559)

it does have 0.6.532 which dates back to December

Not sure why Travis is using that mirror — that’s certainly not a mirror I’ve defined in my deps.edn

https://travis-ci.community/t/disable-google-maven-central/5301 — probably a question for tools.deps?

tools.deps is not doing anything to use that

tools.deps does support mirrors in settings.xml so if you set that up, it should take effect

Hm, I need to learn about maven now 😄 — killing the cache as the thread suggested seems to have fixed things.