The best way to understand how/why this happens is to look at the source of
>!!. In short, the thread making the call doesn't block on the channel. It
starts an async put, then waits on a promise that is delivered by the async
put. So it works something like this:
1) Calling thread creates a promi
I should be more precise there, by "consumed" I meant buffered or consumed.
On Wed, Jun 27, 2018 at 10:17 AM Justin Smith wrote:
> I doubt core.async would ever make promises about the behavior of a
> blocking put that gets forcibly cancelled. It promises that the blocking
> put doesn't return u
I doubt core.async would ever make promises about the behavior of a
blocking put that gets forcibly cancelled. It promises that the blocking
put doesn't return until the message is consumed, but that's not the same
as promising that the message isn't consumed if the blocking put is
forcibly cancell
I think its due to ctrl+c, not sure what it actually does, but maybe it didn't
actually kill the blocked thread?
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new me
I guess the interrupt doesn't really obliterate the fourth put attempt, and
that put proceeds in background when you first take.
On Wednesday, June 27, 2018 at 5:12:45 AM UTC+10, jonah wrote:
>
> Hi folks,
>
> It's been a while since I've used core.async. Documentation suggests that
>
> (chan n)
Hi folks,
It's been a while since I've used core.async. Documentation suggests that
(chan n)
where n is a number creates a fixed size channel buffer supporting n
elements.
The below clj repl session seems to indicate that I can put 4 items into a
3-sized buffer:
user=> (def c (async/chan 3))
#
