Re: Blocking behavior of >!! ?
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:
>
> -
> clojure.core.async/>!!
> ([port val])
> puts a val into port. nil values are not allowed. Will block if no
> buffer space is available. Returns true unless port is already closed.
>
>
> I have a case where I believe that the channel has no buffer, I park a
> "pseudothread" in a go block reading off that channel via (lexically, not temporally), put to the unbuffered channel via >!!:
>
> (let [c (chan) ;; NO BUFFER!
> d (go ( e (>!! c 42)] ;; blocking write to c, will unpark c's pseudothread
> (println {:c-coughs-up '(this will hang ( :d-coughs-up ( :what's-ee})
> (close! c) (close! d))
>
> {:c-coughs-up (this will hang (
>
> This case leads me to wonder whether the documentation might read
>
> >!! will block if there is no buffer space available *and* if there is
> no *rendezvous *available, that is, no pseudothread parked waiting for
> but it's more likely that I completely misunderstand core.async because I
> just made up the notion of a pseudothread in my struggle to understand!
>
>
>
>
--
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 members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/clojure/0b243161-9598-490e-ad81-93d53a76a21b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Blocking behavior of >!! ?
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 case where the consuption happens
immediately doesn't mean the call doesn't block.
On Mon, May 20, 2019 at 9:33 AM LaurentJ wrote:
>
> ...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
>> iterate over takers ready to consume the value.
>> https://github.com/clojure/core.async/blob/91e6971a05fa49ca639fc1b7793141dd5f3d32ce/src/main/clojure/clojure/core/async/impl/channels.clj#L116
>>
>>
>>
>> Le lundi 20 mai 2019 15:18:17 UTC+2, Brian Beckman a écrit :
>>>
>>> Thanks, Thomas. I shouldn't have included the quoted code about (>> my question because it distracts from what I really want to know, and what
>>> I want to know is all about how (go (>> so that (>!! c 42) doesn't block.
>>>
>>> The following is an attempt to clarify my question. I first (go (>> give the name d to the result, which is a channel that I am going read-from
>>> later. Channel d is "connected to" or "relayed from" c. I then (>!! c 42),
>>> and then (>> wasted your attention by writing some code that would block (>> weren't quoted.
>>>
>>> Here is the part I don't understand: the documentation says that (>!! c 42)
>>> will block "if there is no buffer space available," and the documentation
>>> does not specify any other conditions. Well, I created c with no buffer
>>> space, so, (>!! c 42) must block unless something else "makes buffer space
>>> available," assuming the documentation is correct. The only other
>>> interaction with c that could possibly be alive at the time when I do (>!!
>>> c 42), is (go (>> assuming the documentation is correct. My understanding of (>> suspicious of my understanding), is that (>> available, not a buffer. If that understanding is correct, then (>!! c 42)
>>> should block because there is no buffer available.
>>>
>>> On Sunday, May 19, 2019 at 1:48:16 PM UTC-7, Thomas Heller wrote:
(>>> by the first go (running in a different thread). So it is blocking until
something puts another value into c. Since nothing ever does your program
hangs.
If it helps you can read "go" as "please run this somewhere else, possibly
at a different time" and let the current thread continue after the go.
I can't explain this very well but the documentation aspect is accurate.
On Sunday, May 19, 2019 at 7:33:07 PM UTC+2, Brian Beckman wrote:
>
> The documentation for >!! reads:
>
> -
> clojure.core.async/>!!
> ([port val])
> puts a val into port. nil values are not allowed. Will block if no
> buffer space is available. Returns true unless port is already closed.
>
>
> I have a case where I believe that the channel has no buffer, I park a
> "pseudothread" in a go block reading off that channel via (lexically, not temporally), put to the unbuffered channel via >!!:
>
> (let [c (chan) ;; NO BUFFER!
> d (go ( e (>!! c 42)] ;; blocking write to c, will unpark c's pseudothread
> (println {:c-coughs-up '(this will hang ( :d-coughs-up ( :what's-ee})
> (close! c) (close! d))
>
> {:c-coughs-up (this will hang (
>
> This case leads me to wonder whether the documentation might read
>
> >!! will block if there is no buffer space available and if there is no
> rendezvous available, that is, no pseudothread parked waiting for
> but it's more likely that I completely misunderstand core.async because I
> just made up the notion of a pseudothread in my struggle to understand!
>
>
>
> --
> 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 members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/clojure/456c5363-a2fd-49e8-9de5-73ae9ffae075%40googlegroups.com.
> For more options, visit
Re: Blocking behavior of >!! ?
...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
> iterate over takers ready to consume the value.
>
> https://github.com/clojure/core.async/blob/91e6971a05fa49ca639fc1b7793141dd5f3d32ce/src/main/clojure/clojure/core/async/impl/channels.clj#L116
>
>
>
> Le lundi 20 mai 2019 15:18:17 UTC+2, Brian Beckman a écrit :
>>
>> Thanks, Thomas. I shouldn't have included the quoted code about (> in my question because it distracts from what I really want to know, and
>> what I want to know is all about how (go (> available" so that (>!! c 42) doesn't block.
>>
>> The following is an attempt to clarify my question. I first (go (> and give the name d to the result, which is a channel that I am going
>> read-from later. Channel d is "connected to" or "relayed from" c. I then
>> (>!! c 42), and then (> works. I wasted your attention by writing some code that would block (> c) if it weren't quoted.
>>
>> Here is the part I don't understand: the documentation says that (>!! c
>> 42) will block "if there is no buffer space available," and the
>> documentation does not specify any other conditions. Well, I created c with
>> no buffer space, so, (>!! c 42) must block unless something else "makes
>> buffer space available," assuming the documentation is correct. The only
>> other interaction with c that could possibly be alive at the time when I do
>> (>!! c 42), is (go (> available," assuming the documentation is correct. My understanding of (> c) (and I am suspicious of my understanding), is that (> rendezvous available, not a buffer. If that understanding is correct, then
>> (>!! c 42) should block because there is no buffer available.
>>
>> On Sunday, May 19, 2019 at 1:48:16 PM UTC-7, Thomas Heller wrote:
>>>
>>> (>> taken by the first go (running in a different thread). So it is blocking
>>> until something puts another value into c. Since nothing ever does your
>>> program hangs.
>>>
>>> If it helps you can read "go" as "please run this somewhere else,
>>> possibly at a different time" and let the current thread continue after the
>>> go.
>>>
>>> I can't explain this very well but the documentation aspect is accurate.
>>>
>>> On Sunday, May 19, 2019 at 7:33:07 PM UTC+2, Brian Beckman wrote:
The documentation for >!! reads:
-
clojure.core.async/>!!
([port val])
puts a val into port. nil values are not allowed. Will block if no
buffer space is available. Returns true unless port is already closed.
I have a case where I believe that the channel has no buffer, I park a
"pseudothread" in a go block reading off that channel via >>> (lexically, not temporally), put to the unbuffered channel via >!!:
(let [c (chan) ;; NO BUFFER!
d (go (>>> e (>!! c 42)] ;; blocking write to c, will unpark c's
pseudothread
(println {:c-coughs-up '(this will hang (>>> :d-coughs-up (>>> :what's-ee})
(close! c) (close! d))
{:c-coughs-up (this will hang (>>>
This case leads me to wonder whether the documentation might read
>!! will block if there is no buffer space available *and* if there
is no *rendezvous *available, that is, no pseudothread parked waiting
for >>>
but it's more likely that I completely misunderstand core.async because
I just made up the notion of a pseudothread in my struggle to understand!
--
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 members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/clojure/456c5363-a2fd-49e8-9de5-73ae9ffae075%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Blocking behavior of >!! ?
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.
https://github.com/clojure/core.async/blob/91e6971a05fa49ca639fc1b7793141dd5f3d32ce/src/main/clojure/clojure/core/async/impl/channels.clj#L116
Le lundi 20 mai 2019 15:18:17 UTC+2, Brian Beckman a écrit :
>
> Thanks, Thomas. I shouldn't have included the quoted code about ( my question because it distracts from what I really want to know, and what
> I want to know is all about how (go ( so that (>!! c 42) doesn't block.
>
> The following is an attempt to clarify my question. I first (go ( and give the name d to the result, which is a channel that I am going
> read-from later. Channel d is "connected to" or "relayed from" c. I then
> (>!! c 42), and then ( works. I wasted your attention by writing some code that would block ( c) if it weren't quoted.
>
> Here is the part I don't understand: the documentation says that (>!! c
> 42) will block "if there is no buffer space available," and the
> documentation does not specify any other conditions. Well, I created c with
> no buffer space, so, (>!! c 42) must block unless something else "makes
> buffer space available," assuming the documentation is correct. The only
> other interaction with c that could possibly be alive at the time when I do
> (>!! c 42), is (go ( available," assuming the documentation is correct. My understanding of ( c) (and I am suspicious of my understanding), is that ( rendezvous available, not a buffer. If that understanding is correct, then
> (>!! c 42) should block because there is no buffer available.
>
> On Sunday, May 19, 2019 at 1:48:16 PM UTC-7, Thomas Heller wrote:
>>
>> (> by the first go (running in a different thread). So it is blocking until
>> something puts another value into c. Since nothing ever does your program
>> hangs.
>>
>> If it helps you can read "go" as "please run this somewhere else,
>> possibly at a different time" and let the current thread continue after the
>> go.
>>
>> I can't explain this very well but the documentation aspect is accurate.
>>
>> On Sunday, May 19, 2019 at 7:33:07 PM UTC+2, Brian Beckman wrote:
>>>
>>> The documentation for >!! reads:
>>>
>>> -
>>> clojure.core.async/>!!
>>> ([port val])
>>> puts a val into port. nil values are not allowed. Will block if no
>>> buffer space is available. Returns true unless port is already closed.
>>>
>>>
>>> I have a case where I believe that the channel has no buffer, I park a
>>> "pseudothread" in a go block reading off that channel via >> (lexically, not temporally), put to the unbuffered channel via >!!:
>>>
>>> (let [c (chan) ;; NO BUFFER!
>>> d (go (>> e (>!! c 42)] ;; blocking write to c, will unpark c's pseudothread
>>> (println {:c-coughs-up '(this will hang (>> :d-coughs-up (>> :what's-ee})
>>> (close! c) (close! d))
>>>
>>> {:c-coughs-up (this will hang (>>
>>>
>>> This case leads me to wonder whether the documentation might read
>>>
>>> >!! will block if there is no buffer space available *and* if there is
>>> no *rendezvous *available, that is, no pseudothread parked waiting for
>>> >>
>>> but it's more likely that I completely misunderstand core.async because
>>> I just made up the notion of a pseudothread in my struggle to understand!
>>>
>>>
>>>
>>>
--
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 members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/clojure/8fbd0b5f-3cf8-4f4c-839b-8fce739dafb7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Blocking behavior of >!! ?
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
- https://www.youtube.com/watch?v=enwIIGzhahw
- https://www.youtube.com/watch?v=096pIlA3GDo
On Monday, May 20, 2019 at 3:18:17 PM UTC+2, Brian Beckman wrote:
>
> Thanks, Thomas. I shouldn't have included the quoted code about ( my question because it distracts from what I really want to know, and what
> I want to know is all about how (go ( so that (>!! c 42) doesn't block.
>
> The following is an attempt to clarify my question. I first (go ( and give the name d to the result, which is a channel that I am going
> read-from later. Channel d is "connected to" or "relayed from" c. I then
> (>!! c 42), and then ( works. I wasted your attention by writing some code that would block ( c) if it weren't quoted.
>
> Here is the part I don't understand: the documentation says that (>!! c
> 42) will block "if there is no buffer space available," and the
> documentation does not specify any other conditions. Well, I created c with
> no buffer space, so, (>!! c 42) must block unless something else "makes
> buffer space available," assuming the documentation is correct. The only
> other interaction with c that could possibly be alive at the time when I do
> (>!! c 42), is (go ( available," assuming the documentation is correct. My understanding of ( c) (and I am suspicious of my understanding), is that ( rendezvous available, not a buffer. If that understanding is correct, then
> (>!! c 42) should block because there is no buffer available.
>
> On Sunday, May 19, 2019 at 1:48:16 PM UTC-7, Thomas Heller wrote:
>>
>> (> by the first go (running in a different thread). So it is blocking until
>> something puts another value into c. Since nothing ever does your program
>> hangs.
>>
>> If it helps you can read "go" as "please run this somewhere else,
>> possibly at a different time" and let the current thread continue after the
>> go.
>>
>> I can't explain this very well but the documentation aspect is accurate.
>>
>> On Sunday, May 19, 2019 at 7:33:07 PM UTC+2, Brian Beckman wrote:
>>>
>>> The documentation for >!! reads:
>>>
>>> -
>>> clojure.core.async/>!!
>>> ([port val])
>>> puts a val into port. nil values are not allowed. Will block if no
>>> buffer space is available. Returns true unless port is already closed.
>>>
>>>
>>> I have a case where I believe that the channel has no buffer, I park a
>>> "pseudothread" in a go block reading off that channel via >> (lexically, not temporally), put to the unbuffered channel via >!!:
>>>
>>> (let [c (chan) ;; NO BUFFER!
>>> d (go (>> e (>!! c 42)] ;; blocking write to c, will unpark c's pseudothread
>>> (println {:c-coughs-up '(this will hang (>> :d-coughs-up (>> :what's-ee})
>>> (close! c) (close! d))
>>>
>>> {:c-coughs-up (this will hang (>>
>>>
>>> This case leads me to wonder whether the documentation might read
>>>
>>> >!! will block if there is no buffer space available *and* if there is
>>> no *rendezvous *available, that is, no pseudothread parked waiting for
>>> >>
>>> but it's more likely that I completely misunderstand core.async because
>>> I just made up the notion of a pseudothread in my struggle to understand!
>>>
>>>
>>>
>>>
--
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 members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/clojure/568ddcbe-2e3a-4e6b-a97e-c060e3b7fb37%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Blocking behavior of >!! ?
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 conditions. Well, I created c with no buffer
space, so, (>!! c 42) must block unless something else "makes buffer space
available," assuming the documentation is correct. The only other
interaction with c that could possibly be alive at the time when I do (>!!
c 42), is (go (!! c 42)
should block because there is no buffer available.
On Sunday, May 19, 2019 at 1:48:16 PM UTC-7, Thomas Heller wrote:
>
> ( by the first go (running in a different thread). So it is blocking until
> something puts another value into c. Since nothing ever does your program
> hangs.
>
> If it helps you can read "go" as "please run this somewhere else, possibly
> at a different time" and let the current thread continue after the go.
>
> I can't explain this very well but the documentation aspect is accurate.
>
> On Sunday, May 19, 2019 at 7:33:07 PM UTC+2, Brian Beckman wrote:
>>
>> The documentation for >!! reads:
>>
>> -
>> clojure.core.async/>!!
>> ([port val])
>> puts a val into port. nil values are not allowed. Will block if no
>> buffer space is available. Returns true unless port is already closed.
>>
>>
>> I have a case where I believe that the channel has no buffer, I park a
>> "pseudothread" in a go block reading off that channel via > (lexically, not temporally), put to the unbuffered channel via >!!:
>>
>> (let [c (chan) ;; NO BUFFER!
>> d (go (> e (>!! c 42)] ;; blocking write to c, will unpark c's pseudothread
>> (println {:c-coughs-up '(this will hang (> :d-coughs-up (> :what's-ee})
>> (close! c) (close! d))
>>
>> {:c-coughs-up (this will hang (>
>>
>> This case leads me to wonder whether the documentation might read
>>
>> >!! will block if there is no buffer space available *and* if there is
>> no *rendezvous *available, that is, no pseudothread parked waiting for > .
>>
>> but it's more likely that I completely misunderstand core.async because I
>> just made up the notion of a pseudothread in my struggle to understand!
>>
>>
>>
>>
--
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 members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/clojure/fe9fc48c-d651-434d-8743-0045438291f1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Blocking behavior of >!! ?
(
> The documentation for >!! reads:
>
> -
> clojure.core.async/>!!
> ([port val])
> puts a val into port. nil values are not allowed. Will block if no
> buffer space is available. Returns true unless port is already closed.
>
>
> I have a case where I believe that the channel has no buffer, I park a
> "pseudothread" in a go block reading off that channel via (lexically, not temporally), put to the unbuffered channel via >!!:
>
> (let [c (chan) ;; NO BUFFER!
> d (go ( e (>!! c 42)] ;; blocking write to c, will unpark c's pseudothread
> (println {:c-coughs-up '(this will hang ( :d-coughs-up ( :what's-ee})
> (close! c) (close! d))
>
> {:c-coughs-up (this will hang (
>
> This case leads me to wonder whether the documentation might read
>
> >!! will block if there is no buffer space available *and* if there is
> no *rendezvous *available, that is, no pseudothread parked waiting for
> but it's more likely that I completely misunderstand core.async because I
> just made up the notion of a pseudothread in my struggle to understand!
>
>
>
>
--
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 members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/clojure/8c187aad-b746-490a-b6f8-3abfcdaa7533%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Blocking behavior of >!! ?
The documentation for >!! reads:
-
clojure.core.async/>!!
([port val])
puts a val into port. nil values are not allowed. Will block if no
buffer space is available. Returns true unless port is already closed.
I have a case where I believe that the channel has no buffer, I park a
"pseudothread" in a go block reading off that channel via !!:
(let [c (chan) ;; NO BUFFER!
d (go (!! c 42)] ;; blocking write to c, will unpark c's pseudothread
(println {:c-coughs-up '(this will hang (!! will block if there is no buffer space available *and* if there is no
*rendezvous *available, that is, no pseudothread parked waiting for http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/clojure/ef62965f-6132-4f18-9bb8-3d569f10dbdc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
