Fork me on GitHub
#core-async
<
2019-07-25
>
mpenet14:07:21

just curious, would it be desirable to have close! on a async/thread kill the internal thread? I imagine it's by design the way it is

mpenet14:07:56

it just closes the chan atm, if you (blindly and prolly wrongly) loop recur without checking for a poison pill the thread never actually exits

mpenet14:07:01

I understand it might be tricky to achieve without doing it via c.async internals since to get the close! signal you need to pull from it (using the public api)

mpenet14:07:49

I guess the same applies to async/go actually (didn't check)

ghadi14:07:03

What does "kill" mean?

mpenet14:07:01

(future-cancel ...)

mpenet14:07:27

in which the "if possible" part of the docstring says it's not something that can be guaranteed so better designing it right early on I guess

mpenet14:07:45

got my answer

leonoel14:07:12

I understand the "if possible" part as "the future can be already completed, in which case it will be a no-op"

Alex Miller (Clojure team)14:07:34

no, it's "may not be able to do anything"

leonoel14:07:57

but if the future is still pending the running thread is guaranteed to get the interruption signal, right ?

Alex Miller (Clojure team)14:07:47

what interruption signal?

leonoel14:07:59

Thread/interrupt

ghadi14:07:29

interrupt messes with channel locks :white_frowning_face:

markmarkmark14:07:58

the thread will get the interrupt, but the code that is running on the thread might not pay attention to the interrupt

ghadi15:07:02

If you get interrupted within the channel lock, it is possible that the channel lock isn't released

noisesmith17:07:22

future-cancel sets a flag that some things (IO polling, sleep) are smart enough to check, it's a no-op if you are in a CPU-bound hot loop that never polls on IO or sleeps (or some other thing that checks cancellation I might be forgetting)

noisesmith17:07:49

there's another method that actually kills threads, but it breaks a lot of java classes so isn't a sane thing to use