[Haskell-cafe] pure Haskell database

Sterling Clover s.clover at gmail.com
Fri Oct 3 20:46:31 EDT 2008

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).


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 at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

More information about the Haskell-Cafe mailing list