On 20/06/12 10:56, Thomas Hood wrote:
> I can imagine that it will take a lot of care to avoid introducing races
> inside dnsmasq.
It's OK: notification of new interfaces comes via netlink, so it gets
synchronised via the select() call just like everything else.
Have I mentioned yet that Simon is a hero?
:-)
New code is in git (and I released 2.63test1) change --bind-interfaces
to --bind-dynamic as see how it goes.
>
> Do we have to worry about races outside of dnsmasq? Suppose someone was
> running dnsmasq in unbound mode and has now switched to the new improved
> dnsmasq in bind-interfaces-dynamically mode. Now an interface comes up
> but there is a delay before dnsmasq notices this and starts listening on
> it. Problem?
Because it's using netlink rather than polling, the delay is pretty
short (I know that's not a solution to races, but it does help.)
On 20/06/12 10:56, Thomas Hood wrote:
> I can imagine that it will take a lot of care to avoid introducing races
> inside dnsmasq.
It's OK: notification of new interfaces comes via netlink, so it gets
synchronised via the select() call just like everything else.
Have I mentioned yet that Simon is a hero?
:-)
New code is in git (and I released 2.63test1) change --bind-interfaces
to --bind-dynamic as see how it goes.
> -dynamically mode. Now an interface comes up
> Do we have to worry about races outside of dnsmasq? Suppose someone was
> running dnsmasq in unbound mode and has now switched to the new improved
> dnsmasq in bind-interfaces
> but there is a delay before dnsmasq notices this and starts listening on
> it. Problem?
Because it's using netlink rather than polling, the delay is pretty
short (I know that's not a solution to races, but it does help.)
Simon.