Thanks everyone for your answers. I understand much better now. I just had
to make up some words like "rendezvous" and "pseudothread" to help me piece
together these implicit concepts.
On Sunday, May 19, 2019 at 10:33:07 AM UTC-7, Brian Beckman wrote:
>
> The documentation for >!! reads:
>
>
I might be missing something here, but when it is mentioned that
something blocks, it's implicit in all cases that there's some
condition that allows it to proceed (even immediately) if satisfied.
If there's no buffer space it blocks, until that value is consumed.
Just because we can construct a
...waiting -offers +takers
Le lundi 20 mai 2019 18:30:36 UTC+2, LaurentJ a écrit :
>
> You are not wrong.
>
> I think it was obvious for the author to consider that >!! will not block
> if there are waiting offers.
>
> You can see it in the code, if no buffer is set the write method will
>
You are not wrong.
I think it was obvious for the author to consider that >!! will not block
if there are waiting offers.
You can see it in the code, if no buffer is set the write method will
iterate over takers ready to consume the value.
The (go (!! c 42) will
use that pending take and immediately fulfill it without checking the
buffer (there is none).
I really can't explain this very well so I'd recommend watching some of the
talks on core.async instead. All the topics are covered
- https://vimeo.com/100518968
-
Thanks, Thomas. I shouldn't have included the quoted code about (!! c 42) doesn't block.
The following is an attempt to clarify my question. I first (go (!! c 42),
and then (!! c 42)
will block "if there is no buffer space available," and the documentation
does not specify any other
