2009/4/23 Christophe Grand <christo...@cgrand.net>: > > Laurent PETIT a écrit : >> I guess you're right. But a little warning in the javadoc could help >> newcomers not shoot themselves in the foot. >> And the problem is, calling directly (second) without calling (first) >> would work most of the time. I wanted to make it fail every time => >> same behaviour whatever the input data are. >> > > Such a guarantee implies a side effect on the first seq is realized!
don't understand. > >>> Neither do I. Updates to the atom are serialized by the lazy-seq >>> realization, so we don't even need an atom: a simple volatile field >>> should do the trick. No? >>> >> >> Yes, what would be the prettier way to do this ? I could think of some >> hackish but working array of one element :-) ? >> I don't think (with-local-vars will work, since the produced seqs >> could not be transported among threads anymore). >> > > I think that 1-elt arrays don't work well with threads, that's why I > suggested a volatile field. > But I'm not a concurrency expert (just received my copy of Java > Concurrency In Practice :-D) Have a nice read. I myself just bought "Concepts, Techniques, and Models of Computer Programming". Seems like we're going to not sleep a lot the days following our respective books deliveries :-) --~--~---------~--~----~------------~-------~--~----~ 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 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 -~----------~----~----~----~------~----~------~--~---