@Timothy: Looking forward to your changes. Thanks for all the existing work with core.async! (I was half tempted to switch to Scala to use Akka right before core.async came out.)
On Tue, Jan 14, 2014 at 10:30 AM, t x <txrev...@gmail.com> wrote: > @Ghadi, > > > Are you referring to the race condition between: > > (check if channel is closed) > ### BAM SOMETHING HAPPENS > (put something on to the channel) > > ? > > > I agree it's a race condition, however after some refactoring, I no longer > care if I'm >!-ing onto a closed channel, as long as I eventually know that > the channel is closed. (Usage case; I have a list of channels that I need > to blast; I want to drop the already closed channels from the list.) > > > On Tue, Jan 14, 2014 at 9:56 AM, Timothy Baldridge > <tbaldri...@gmail.com>wrote: > >> It's a known problem (putting into a closed channel), and one we have a >> possible solution for (it's in one of the branches of core.async). I'll >> bring it up this Friday and see if we can't make some progress on the code. >> >> Timothy >> >> >> On Tue, Jan 14, 2014 at 10:43 AM, Ghadi Shayban <gshay...@gmail.com>wrote: >> >>> This code actually results in a subtle race condition as channels need >>> to be locked internally. It also won't work for other implementations of >>> channel, of which there are several in core.async besides >>> ManytoManyChannel. (For example, map< returns a reified channel.) Knowing >>> whether a channel is closed at put-time (with some restrictions) is a >>> current work item in core.async. >>> >>> >>> >>> On Monday, January 13, 2014 5:12:58 AM UTC-5, t x wrote: >>> >>>> (let [c (async/chan 10)] >>>> (println @(.-closed c)) >>>> (async/close! c) >>>> (println @(.-closed c))) >>>> >>>> >>>> And we're done. Sorry for the spam. Last message send in case someone >>>> finds my question via Google. >>>> >>>> >>>> On Mon, Jan 13, 2014 at 2:11 AM, t x <txre...@gmail.com> wrote: >>>> >>>>> Is there anyway, to "pierce the deftype" >>>>> >>>>> https://github.com/clojure/core.async/blob/master/src/ >>>>> main/clojure/clojure/core/async/impl/channels.clj#L31 >>>>> >>>>> to read the "closed" field of the ManytoMany Channel? >>>>> >>>>> That's basically all I need to do. >>>>> >>>>> >>>>> On Mon, Jan 13, 2014 at 1:47 AM, t x <txre...@gmail.com> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I have the following problem: >>>>>> >>>>>> I have a set of channels #{ ... } >>>>>> >>>>>> some of the channels are closed, some of the channels are open >>>>>> >>>>>> * for the channels that are open, I want to (>! chan msg) >>>>>> >>>>>> * for the channels that are closed, I want to remove the channel >>>>>> from the hash-set >>>>>> >>>>>> >>>>>> ## Problems: >>>>>> >>>>>> (1) (>! ... ...) always returns nil, regardless of whether the >>>>>> channel is open or closed, and thus useless >>>>>> >>>>>> (2) I could use (<! ... ) to read from the channel to see if it's >>>>>> nil, but then would remove an item from the channel, which I don't want >>>>>> to >>>>>> do >>>>>> >>>>>> >>>>>> ## Question: >>>>>> >>>>>> Thus, without changing the state of the channel, is there a way to >>>>>> see if the channel is open/closed? >>>>>> >>>>>> Thanks! >>>>>> >>>>> >>>>> >>>> -- >>> -- >>> 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.
