core-async

mpenet 2019-07-25T14:18:21.019300Z

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

mpenet 2019-07-25T14:18:56.020Z

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

mpenet 2019-07-25T14:20:01.020700Z

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)

mpenet 2019-07-25T14:20:49.021100Z

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

ghadi 2019-07-25T14:24:03.021700Z

What does "kill" mean?

mpenet 2019-07-25T14:24:34.021900Z

exit

mpenet 2019-07-25T14:25:01.022600Z

(future-cancel ...)

mpenet 2019-07-25T14:26:27.023800Z

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

mpenet 2019-07-25T14:26:45.024Z

got my answer

2019-07-25T14:30:12.024900Z

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

alexmiller 2019-07-25T14:30:34.025100Z

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

2019-07-25T14:31:57.026100Z

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

alexmiller 2019-07-25T14:32:47.026400Z

what interruption signal?

2019-07-25T14:32:59.026700Z

Thread/interrupt

ghadi 2019-07-25T14:39:29.027500Z

interrupt messes with channel locks :white_frowning_face:

markmarkmark 2019-07-25T14:56:58.028100Z

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

ghadi 2019-07-25T15:02:02.029Z

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

2019-07-25T17:07:22.030Z

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)

2019-07-25T17:07:49.030500Z

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