Clojurians Log v2
core-async
@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?
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 ?
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
Hum... Does async/thread works off a thread pool?
My initial thought was to wrap the work in async/thread in a future as well and interup that, but I felt dumb double spawning a thread just for that
async/thread does, but async/thread is not special - you can just make your own Thread and do channel stuff on it too
Ya, that can work. Needs a bit more scaffolding but makes sense.
@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?
You're right, that's why I asked about interup.
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.
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.