Ah, scratch that. I see from the source it indeed closes the source channel. Was hoping that was the clue I needed.
On Mon, Apr 7, 2014 at 11:52 AM, Gary Trakhman <[email protected]>wrote: > I'm currently running into a bug where it seems like channels aren't being > closed down like they should. This manifests in everything blocking up > after many websocket connections. map< and pipe are involved, I think this > is the clue I needed :-). > > #(async/map< pr-str (async/tap a-mult (async/chan))) > > The return value from this function was expected to be a channel that the > jetty7 core.async websocket integration creates and manages during the > lifecycle of a websocket connection. > > if map< isn't returning a channel, then I guess I can't expect the > jetty-7-websockets integration to do the right thing when it tries to close > it! > > > On Mon, Apr 7, 2014 at 11:43 AM, Timothy Baldridge > <[email protected]>wrote: > >> But yes, we should probably at least put a note in the docs for map< >> stating "returning nil from the mapping function can result in undefined >> behavior". Or add an assert somewhere perhaps. >> >> Timothy >> >> >> On Mon, Apr 7, 2014 at 9:36 AM, James Reeves <[email protected]>wrote: >> >>> This looks like a bug to me. A lot of the internal core.async functions >>> rely on nil values indicating the channel is closed. >>> >>> - James >>> >>> >>> On 7 April 2014 16:26, Alejandro Ciniglio <[email protected]> wrote: >>> >>>> Using core.async, I've understood the convention to be that if you take >>>> nil from a channel, that channel is closed. This seems to hold for most >>>> cases, but I've found a corner case when using map< that lets you pull nil >>>> from a channel that is not closed. >>>> >>>> (def a (chan)) >>>> (def c (map< seq a)) >>>> (go (prn (<! c))) >>>> (>!! a []) >>>> ; => nil nil ;; [one nil is printed, one is returned] >>>> (go (prn (<! c))) >>>> (>!! a [1]) >>>> ; => nil (1) >>>> >>>> This can be chained as well (e.g. (map< identity (map< seq a)) ), and >>>> nils just flow through. >>>> >>>> From looking at the implementation, it's apparent that this happens >>>> because the function application of map happens when taking from the output >>>> channel so nil is not technically on the channel, (unless it flows through >>>> to another map). >>>> >>>> Is this a bug or is my mental model of nil => closed incorrect? >>>> >>>> Thanks, >>>> Alejandro >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Clojure" group. >>>> To post to this group, send email to [email protected] >>>> Note that posts from new members are moderated - please be patient with >>>> your first post. >>>> To unsubscribe from this group, send email to >>>> [email protected] >>>> 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 [email protected]. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To post to this group, send email to [email protected] >>> Note that posts from new members are moderated - please be patient with >>> your first post. >>> To unsubscribe from this group, send email to >>> [email protected] >>> 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 [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> "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 [email protected] >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> [email protected] >> 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 [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to [email protected] Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to [email protected] 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
