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
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
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)
I guess the same applies to async/go actually (didn't check)
What does "kill" mean?
exit
(future-cancel ...)
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
got my answer
I understand the "if possible" part as "the future can be already completed, in which case it will be a no-op"
no, it's "may not be able to do anything"
but if the future is still pending the running thread is guaranteed to get the interruption signal, right ?
what interruption signal?
Thread/interrupt
interrupt messes with channel locks :white_frowning_face:
the thread will get the interrupt, but the code that is running on the thread might not pay attention to the interrupt
If you get interrupted within the channel lock, it is possible that the channel lock isn't released
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)
there's another method that actually kills threads, but it breaks a lot of java classes so isn't a sane thing to use