Re: core.async: close! and control channels
It appears that you cannot call close! within a go block and so to signal the end of input to a channel you have to use another channel upon which the receiver can alt!. That's shouldn't be true. What problems did you run into with this? And yes, channels and go's are automatically GC'd when they can no longer be access by the system. So these channels/gos get GC'd as fast as they are created. (loop [] (let [c (chan)] (go (! c)) (recur))) Timothy -- -- 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. For more options, visit https://groups.google.com/groups/opt_out.
Re: core.async: close! and control channels
True, but I'll mention the semantics of channels once again. Go blocks are attached to channels, and channels exist on their own as values. No where in this entire system is there some global list of channels or go blocks (except for in the executors, but let's not get into that right now). This means that entire chains of gos and channels can be reclaimed by the GC if neither end of the chain is anchored in a GC root. Timothy On Wed, Jul 17, 2013 at 8:17 AM, Laurent PETIT laurent.pe...@gmail.comwrote: 2013/7/17 Timothy Baldridge tbaldri...@gmail.com: It appears that you cannot call close! within a go block and so to signal the end of input to a channel you have to use another channel upon which the receiver can alt!. That's shouldn't be true. What problems did you run into with this? Silly suggestion : maybe the OP is trying to call close! on a channel which is unbuffered, after having put a value. I can imagine, then, that it is only when a consumer has taken the value out of the unbuffered channel, that the producer will be unblocked, and the call to close! will be executed. So maybe using a channel of size 1 may help make the symptom disappear ? And yes, channels and go's are automatically GC'd when they can no longer be access by the system. So these channels/gos get GC'd as fast as they are created. (loop [] (let [c (chan)] (go (! c)) (recur))) Timothy -- -- 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. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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. For more options, visit https://groups.google.com/groups/opt_out. -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- -- 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. For more options, visit https://groups.google.com/groups/opt_out.
Re: core.async: close! and control channels
2013/7/17 Timothy Baldridge tbaldri...@gmail.com: It appears that you cannot call close! within a go block and so to signal the end of input to a channel you have to use another channel upon which the receiver can alt!. That's shouldn't be true. What problems did you run into with this? Silly suggestion : maybe the OP is trying to call close! on a channel which is unbuffered, after having put a value. I can imagine, then, that it is only when a consumer has taken the value out of the unbuffered channel, that the producer will be unblocked, and the call to close! will be executed. So maybe using a channel of size 1 may help make the symptom disappear ? And yes, channels and go's are automatically GC'd when they can no longer be access by the system. So these channels/gos get GC'd as fast as they are created. (loop [] (let [c (chan)] (go (! c)) (recur))) Timothy -- -- 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. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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. For more options, visit https://groups.google.com/groups/opt_out.
Re: core.async: close! and control channels
The problem I am having is in the function at line 41 of https://github.com/nodename/async-plgd/blob/master/src/hoare/coroutines.clj. Any insight into this is appreciated. -A On Wed, Jul 17, 2013 at 7:23 AM, Timothy Baldridge tbaldri...@gmail.comwrote: True, but I'll mention the semantics of channels once again. Go blocks are attached to channels, and channels exist on their own as values. No where in this entire system is there some global list of channels or go blocks (except for in the executors, but let's not get into that right now). This means that entire chains of gos and channels can be reclaimed by the GC if neither end of the chain is anchored in a GC root. Timothy On Wed, Jul 17, 2013 at 8:17 AM, Laurent PETIT laurent.pe...@gmail.comwrote: 2013/7/17 Timothy Baldridge tbaldri...@gmail.com: It appears that you cannot call close! within a go block and so to signal the end of input to a channel you have to use another channel upon which the receiver can alt!. That's shouldn't be true. What problems did you run into with this? Silly suggestion : maybe the OP is trying to call close! on a channel which is unbuffered, after having put a value. I can imagine, then, that it is only when a consumer has taken the value out of the unbuffered channel, that the producer will be unblocked, and the call to close! will be executed. So maybe using a channel of size 1 may help make the symptom disappear ? And yes, channels and go's are automatically GC'd when they can no longer be access by the system. So these channels/gos get GC'd as fast as they are created. (loop [] (let [c (chan)] (go (! c)) (recur))) Timothy -- -- 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. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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. For more options, visit https://groups.google.com/groups/opt_out. -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- -- 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. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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. For more options, visit https://groups.google.com/groups/opt_out.
Re: core.async: close! and control channels
After a channel is closed, any gets (!) from the channel will return nil. I think some part of your code is taking that nil return value and trying to forward it on to a channel. That's what the error is about. Timothy On Wed, Jul 17, 2013 at 11:02 AM, Alan Shaw noden...@gmail.com wrote: The problem I am having is in the function at line 41 of https://github.com/nodename/async-plgd/blob/master/src/hoare/coroutines.clj. Any insight into this is appreciated. -A On Wed, Jul 17, 2013 at 7:23 AM, Timothy Baldridge tbaldri...@gmail.comwrote: True, but I'll mention the semantics of channels once again. Go blocks are attached to channels, and channels exist on their own as values. No where in this entire system is there some global list of channels or go blocks (except for in the executors, but let's not get into that right now). This means that entire chains of gos and channels can be reclaimed by the GC if neither end of the chain is anchored in a GC root. Timothy On Wed, Jul 17, 2013 at 8:17 AM, Laurent PETIT laurent.pe...@gmail.comwrote: 2013/7/17 Timothy Baldridge tbaldri...@gmail.com: It appears that you cannot call close! within a go block and so to signal the end of input to a channel you have to use another channel upon which the receiver can alt!. That's shouldn't be true. What problems did you run into with this? Silly suggestion : maybe the OP is trying to call close! on a channel which is unbuffered, after having put a value. I can imagine, then, that it is only when a consumer has taken the value out of the unbuffered channel, that the producer will be unblocked, and the call to close! will be executed. So maybe using a channel of size 1 may help make the symptom disappear ? And yes, channels and go's are automatically GC'd when they can no longer be access by the system. So these channels/gos get GC'd as fast as they are created. (loop [] (let [c (chan)] (go (! c)) (recur))) Timothy -- -- 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. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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. For more options, visit https://groups.google.com/groups/opt_out. -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- -- 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. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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.
Re: core.async: close! and control channels
Ah, that's put me on the right track. Thanks Timothy! -A On Wed, Jul 17, 2013 at 10:16 AM, Timothy Baldridge tbaldri...@gmail.comwrote: After a channel is closed, any gets (!) from the channel will return nil. I think some part of your code is taking that nil return value and trying to forward it on to a channel. That's what the error is about. Timothy On Wed, Jul 17, 2013 at 11:02 AM, Alan Shaw noden...@gmail.com wrote: The problem I am having is in the function at line 41 of https://github.com/nodename/async-plgd/blob/master/src/hoare/coroutines.clj. Any insight into this is appreciated. -A On Wed, Jul 17, 2013 at 7:23 AM, Timothy Baldridge tbaldri...@gmail.comwrote: True, but I'll mention the semantics of channels once again. Go blocks are attached to channels, and channels exist on their own as values. No where in this entire system is there some global list of channels or go blocks (except for in the executors, but let's not get into that right now). This means that entire chains of gos and channels can be reclaimed by the GC if neither end of the chain is anchored in a GC root. Timothy On Wed, Jul 17, 2013 at 8:17 AM, Laurent PETIT laurent.pe...@gmail.comwrote: 2013/7/17 Timothy Baldridge tbaldri...@gmail.com: It appears that you cannot call close! within a go block and so to signal the end of input to a channel you have to use another channel upon which the receiver can alt!. That's shouldn't be true. What problems did you run into with this? Silly suggestion : maybe the OP is trying to call close! on a channel which is unbuffered, after having put a value. I can imagine, then, that it is only when a consumer has taken the value out of the unbuffered channel, that the producer will be unblocked, and the call to close! will be executed. So maybe using a channel of size 1 may help make the symptom disappear ? And yes, channels and go's are automatically GC'd when they can no longer be access by the system. So these channels/gos get GC'd as fast as they are created. (loop [] (let [c (chan)] (go (! c)) (recur))) Timothy -- -- 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. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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. For more options, visit https://groups.google.com/groups/opt_out. -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- -- 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. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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
core.async: close! and control channels
It appears that you cannot call close! within a go block and so to signal the end of input to a channel you have to use another channel upon which the receiver can alt!. Some channels that are not stateful, such as a plain copier, would need no such mechanism. Or would it be good to use such a thing so the channel will get collected? Further, if I want to have a chain of coroutines pipelining data, it would appear that control channels must be threaded through all of them as long as at least one of them must be notified of end of input. Is any of this correct? -A -- -- 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. For more options, visit https://groups.google.com/groups/opt_out.
Re: core.async: close! and control channels
My code is at https://github.com/nodename/async-plgd . Here I reproduce Hoare's coroutines from the CSP paper, and find that none of the examples with pipelined coroutines work reliably. I'd appreciate any advice. On Tue, Jul 16, 2013 at 4:34 PM, Alan Shaw noden...@gmail.com wrote: It appears that you cannot call close! within a go block and so to signal the end of input to a channel you have to use another channel upon which the receiver can alt!. Some channels that are not stateful, such as a plain copier, would need no such mechanism. Or would it be good to use such a thing so the channel will get collected? Further, if I want to have a chain of coroutines pipelining data, it would appear that control channels must be threaded through all of them as long as at least one of them must be notified of end of input. Is any of this correct? -A -- -- 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. For more options, visit https://groups.google.com/groups/opt_out.
