Re: [Zinq-general] Patch to open data.cdb no more than once per second

I like SIGHUP as well but it has the drawback of requiring signal safe
code. Any time you add async behavior to a system testing becomes
necessary and is much more difficult to do in a complete manner.  Also
In the past signals have had problems on many OS, most I think have
been fixed but maybe not.

On Fri, Mar 27, 2009 at 4:26 AM, Laurent Bercot <[email protected]> wrote:
>> The idea is to minimize the per query overhead.  I don't know that
>> trading a mmap/munmap per query for a stat per query would be that
>> great of a trade.  Reopening data.cdb only upon receipt of, say, a
>> SIGHUP, would be even better, but that would *really* surprise people.
>
>  By patching djbdns (no matter your choice of patches) you are already
> changing djbdns' behaviour. There's no harm in making changes to the
> interface as long as you properly document them.
>
>  tinydns' current behaviour is to open data.cdb for every query. The
> advantage of this design is that the new data is served automatically
> as soon as data.cdb changes. The drawback is a performance impact.
>  The "one-second" patch takes away the guarantee. The new guarantee
> it offers is "new data is served at most one second after data.cdb
> changes". The gain is better performance. Is the trade-off interesting?
>
>  Notifying the server of a data change (for instance with a SIGHUP)
> gives you the best of both worlds:
>  - best performance as long as data.cdb doesn't change
>  - new data is published as soon as tinydns receives a SIGHUP, no
> timeout necessary.
>  - the drawback is a change to the interface; again, I don't think it
> matters as long as you document the new behaviour.
>
>  If you're going to patch tinydns anyway, go the whole way and give
> strong guarantees, even if it means changing the interface. I favour
> the SIGHUP patch over the one-second patch.
>
> --
>  Laurent
>