Fork me on GitHub
#core-async
<
2020-03-05
>
didibus07:03:26

@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

didibus07:03:42

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

didibus07:03:33

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

didibus07:03:52

And log something on timeout

didibus07:03:46

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

didibus07:03:35

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

mccraigmccraig08:03:18

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

mpenet09:03:30

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

mpenet09:03:42

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

mccraigmccraig09:03:56

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 ?

leonoel10:03:02

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

leonoel10:03:27

you may interrupt that other job accidentally

mccraigmccraig11:03:20

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

leonoel11:03:25

not impossible, but surprisingly hard to get right

mccraigmccraig11:03:13

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

leonoel11:03:33

that looks like a future

mccraigmccraig11:03:03

it does rather - which makes sense

Alex Miller (Clojure team)13:03:37

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.

Alex Miller (Clojure team)13:03:47

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

didibus03:03:32

Hum... Does async/thread works off a thread pool?

didibus03:03:21

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

Alex Miller (Clojure team)04:03:44

async/thread does, but async/thread is not special - you can just make your own Thread and do channel stuff on it too

didibus04:03:37

Ya, that can work. Needs a bit more scaffolding but makes sense.

kwladyka10:03:36

@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?

didibus21:03:58

You're right, that's why I asked about interup.

kwladyka10:03:48

I would prefer timeout on thread instead

kwladyka10:03:30

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

orestis14:03:11

I’m seeing this error in TravisCI: Could not find artifact org.clojure:core.async:jar:1.0.567 in central ()

orestis14:03:54

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

Alex Miller (Clojure team)14:03:31

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

orestis14:03:34

Yeah that’s odd

orestis14:03:55

I will raise an issue with Travis

Alex Miller (Clojure team)14:03:25

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

Alex Miller (Clojure team)14:03:43

it does have 0.6.532 which dates back to December

orestis14:03:43

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

Alex Miller (Clojure team)14:03:23

tools.deps is not doing anything to use that

Alex Miller (Clojure team)14:03:53

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

orestis14:03:46

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