durusmail: durus-users: Re: Anybody willing to try BerkeleyDB Storage?
Anybody willing to try BerkeleyDB Storage?
2006-03-16
2006-03-16
Re: Anybody willing to try BerkeleyDB Storage?
2006-03-19
2006-03-20
2006-03-20
2006-03-20
2006-03-21
2006-03-21
2006-03-21
2006-03-21
2006-03-21
2006-03-21
2006-03-21
2006-03-21
2006-03-21
2006-03-21
2006-03-21
2006-03-21
2006-03-21
2006-03-21
Re: Anybody willing to try BerkeleyDB Storage?
Jesus Cea
2006-03-21
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Neil Schemenauer wrote:
> Jesus Cea  wrote:
>> My worse problem now is the single threaded durus server.
>
> I think the best solution to that problem would be to make the
> server multi-threaded, one thread per client.  This is one of the
> few situations where I think threads are probably the best solution.

Easy to say, difficult to do. The simple approach would be to allow
multiple read requests, if the backend allow it. You can use a simple
and efficient rw-lock to arbitrate between reads and commits.

The simple way to keep backward compatibility with previous
single-threaded backends would be to use "deferred" results.

Current durus server receives a request, increments the rw-lock, calls
the backend and waits for the data before continuing (other readers have
to wait). My suggestion would be to check the result status from the
backend. If it is a data item, send it to the demanding client.
Decrement the rw-lock.

If it is a integer, for example, not a data item, it is a "deferred"
result. The server simply stores the integer and the client that made
the request and keeps serving requests. One of the file descriptor it
"select()" would be a "notifier" from the backend.

When the backend have the result, it put it in a queue, the data item
and the integer, and signal the socket.

The server notices the socket notification, takes the entry from the
queue, check the integer to know what client needs that data and send
it. Decrement the rw-lock.

If a write needs the rw-lock and it is busy with readers, keep flushing
the reply queue until the rw-lock is free and then proceed with the write.

So the server can serve several simultaneous reads, keeping
compatibility with not multithreaded backends. And the durus server
doesn't need to be multithreaded either, important to keep the invalid
notifications in sync.

- --
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea@argo.es http://www.argo.es/~jcea/ _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea@jabber.org         _/_/    _/_/          _/_/_/_/_/
                               _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBRCB2YJlgi5GaxT1NAQJHWQP/T5vq5R6vIKr3ZUUvqJpv9yHX9PpLg9cP
1rS7UjXAsvG0gbRneitsbvrrwuxF9iEZYwG6wfxHYflky+5a9MxLMk+Bnc5gD+ft
EuXpByQ6yxVqAzvfHZxOWAMCsa1473AM39ECZlO/WUQW1WZJucmKze1RoAVxX8Rt
e6YC3RDrB4M=
=8kny
-----END PGP SIGNATURE-----
reply