Takafumi Arakaki

The two implementations suggested here seem to leak tasks. It might be possible to avoid this by using `Timer` since it's `close`-able. In general, it'd be nice if we can...

It means that tasks spawn by the function are still running after the function call ends. This violates the _black box rule_; i.e., all the relevant computations end at the...

Don't we need to cancel the other task for that? That's why the black box rule and task cancellation are the two must-have properties of the structured concurrency. (But it...

> notifying `c` Yeah, notifying `c` acts as the cancellation in one direction. We can `close` the `Timer` for cancellation in the other direction.

What happens if you `wait` on the same thing twice and the first call didn't timeout? If you don't clean up the timer in the first one, isn't there a...

Concretely: ```julia c :: Channel wait_timeout(c, 0.1) === nothing && return x = take!(c) wait_timeout(c, 0.1) === nothing && return # the timer from the first `wait_timeout` can fire here...

It's taking two things from the same channel `c`. I thought your plan was to `notify` one of the `cond_` objects in the channel (maybe `c.cond_wait`)?

IIUC it's unsafe to call `schedule(task, err, error=true)` and `throwto(task, err)` with the `task` that is already scheduled. That's how I understand the comments from @vtjnash in https://discourse.julialang.org/t/stop-terminate-a-sub-task-started-with-async/32193/6 Reading the...

OK, so here is what I meant by `Timer`-based implementation (now I changed the return value to `Bool`): ```julia function wait_timeout(c::Channel, timeout::Real) cancel = Atomic{Bool}(false) isready(c) && return true @sync...

> read up on the various links that @tkf posted. Mission accomplished! :laughing: > https://github.com/davidanthoff/CancellationTokens.jl So my initial response was "why not just use `Atomic{Bool}`" but I guess you have...