On Mon, Nov 09, 2009 at 09:42:28PM -0800, Mark Engelberg wrote: >But let's say the agent is responsible some enormous database, and >it's impractical for the in-memory state to hold all the information >that readers might find useful. In this case, I think you're right >that the basic agent functionality doesn't map well to this without >some additional work. It seems like you would need to create a "read >message" which essentially is a function that reads the relevant data >from the database and stores it in some sort of future-like stateful >entity that will block when you deref it until it has been filled by >the agent.
Ok. So, it's the existence of this future-like entity that blocks upon deref until filled is indeed somewhat missing. It's not particularly difficult to implement. This thing could easily create a lazy sequence, in fact, the code would look a lot like the code for seque, with just a separation of the writer from the reader. I'll have to think about it to make sure that it can be used safely. Making it a full queue unstead of just an event handles the common case where I will have a sequence of reads to make. Thanks, David --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
