> > Now imagine two threads T1 and T2 accessing this generator at the same > time. Suppose they reach the same node at the same time, and suppose > that you've protected file deletion and link deletion each > individually with a mutex (and forbade multiple deletions silently). > T1 might delete the file and the link and get to "recur next" before > T2 can call "(next-entry link)". Now T1 goes on but T2 is stuck: > "link" is _gone_ so "(next-entry link)" goes nowhere. >
hmmmmmm. Good point. I'm sure there's a lot to think about, but, at first, that sounds like a challenge. Like now I'm wondering if what you could do is have the generator automatically update the list of handed out iterators automatically. Then I realize you'd have to update eos, too. But the client may already have checked eos. So I see that Rich's idea is more obvious. Rather than making magic streams, he shows how one might do the same thing by sharing a single iterator. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
