[Dnsmasq-discuss] Re : Re : Feature request for dhcp-hostfiles to behave like addn-hosts

[richardvoigt at gmail.com]

On Fri, Dec 17, 2010 at 8:45 AM, Simon Kelley <simon at thekelleys.org.uk> wrote:
> Vincent Cadet wrote:
>> richardvoigt at gmail.com wrote:
>>
>>
>>> I haven't used sqlite, but I would imagine it loses many of its
>>> advantages in  the lease script process-model -- dnsmasq spawns a new
>>> process for every  lease.
>>
>> I've just read SQLite is thread-safe and may be accessed by multiple threads and
>> processes (though they strongly discourage that: «threads are evil»). They use a
>> reader/writer lock mechanism. So it looks like it can be done. I have no idea
>> about the impact upon performance though.
>>
>
> The problem isn't concurrency - calls to the lease-change script are
> serialised. The problem is that each change causes a new process, so
> that would have to open the SQlite database, make the change, and close
> it. It's not obvious that doing that would be cheaper than the current,
> very simple, arrangement.

I was actually comparing to "heavyweight" client-server SQL, like
MySQL or (what I use) PostgreSQL.  In these, the client layer is
extremely lightweight, so setting up new processes is cheap.  Because
of that, using a "heavyweight" database to store the leases may
actually be more efficient than SQLite.

>
> If one were to implement a more sophisticated database management
> arrangement _within_ dnsmasq, SQLite could work well. I'd like to see at

Agreed.

> least one case where the current system is inadequate before doing that.

I share your sentiment.  The current system is extremely flexible and
lets the user choose what database to use.  In my particular scenario,
SQLite wouldn't work at all, because the data is queried non-locally.
So it would only ever be an option for the default managed-by-dnsmasq
lease database, not as a replacement for the external script
mechanism.

>
>
> Cheers,
>
> Simon.
>