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
-~----------~----~----~----~------~----~------~--~---

Reply via email to