So the issue is one writer, many readers across processes? Creating an actual mini-db-server might be the proper way to do this. Expose a simple socket by which other processes can query the DB state. If you need persistence between runs of your main server you can always snapshot on shutdown, or for error-tolerance you can also write to a transactional log (probably with a single writer thread that takes input over a chan). Assuming its still in good shape, haxr [http:// www.haskell.org/haxr/] would simplify writing the socket portion. Depending on how you wrote the surrounding server, you might be able to avoid mvars altogether (i.e. if your server was built in an "agent" style with only a single request handler thread, then state could just be passed between recursive calls [or even stashed in a State monad] and the request serialization would handle concurrency issues for you). Regards, S. On Oct 1, 2008, at 3:09 PM, Manlio Perillo wrote:
Graham Fawcett ha scritto:
Never though about sparse array, what is the advantage? For the complexity, the same of a good hash map. Almost certainly worse complexity than a hash map; but the overhead could be much smaller. If (for example) you only needed a small number of key/value pairs (say, hundreds of thousands), you could implement your "database" trivially, e.g. a NULL-terminated array of key/value structs in shared memory. (Though having separate arrays for keys and values might help cache locality and boost performance). Lookup might be O(n) but with a small-ish N and with such a low overhead, it could
[...] perform very, very well.
This seems an interesting idea, thanks.
Manlio Perillo _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe