On Mon, Nov 9, 2009 at 8:28 PM, David Brown <cloj...@davidb.org> wrote: > Let's say I have some thing that keeps track of the state of some I/O > entity, let's say some kind of file-based storage. There is state > associated with the entity. It's important that only one thread be > able to read or write from this storage at a time, since the state has > to match what the external store's state is (say it's a cache or > something).
Remember that agents also possess some in-memory state. So, I think ideally you want to try to code your problem so that your "writers' send a function to the agent that makes a permanent transformation to the file-based storage, but also updates the in-memory state with some representation of what went on in the file-based storage that will be of use to readers. Then, your reader just calls await to ensure that any writes sent from the same thread have been fully processed by the agent, and then calls deref to access the in-memory state of the agent. You could do this await/deref sequence inside a future if you want to be able to potentially continue getting work done while the read is happening. 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. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---