[bind10-dev] Thinking aloud: Multi-CPU auth

[Danny Mayer]

On 2/9/2011 5:14 AM, Michal 'vorner' Vaner wrote:
> Hello
> 
> On Mon, Feb 07, 2011 at 11:50:32PM -0500, Danny Mayer wrote:
>> How heavily loaded a server is is irrelevant to whether or not you run a
>> server on Windows. The way I usually emulate a fork on Windows is to
> 
> Well, the idea was, if the server would be heavily loaded, it would be
> dedicated. And if DNS server would be the only thing running there, then we
> could maybe give a „recommendation“ to what OS it should be running on. I'm not
> sure how much that is true, though, maybe there are some people who have
> non-dedicated server running a lot of DNS on windows that would need to utilize
> more than one CPU.

Recommendations are unlikely to be useful and cause political problems
in addition. You need to support as many platforms as is reasonably
possible, and the sponsors and other fee-paying clients want. There's
rarely a choice here.

> 
>> create a separate thread, except that in the case of Bind10 the code is
>> not thread-safe so you then have to go through hoops to create a
>> separate process, find a way to reference the memory you wish to "share"
>> and make sure you find all of the pieces you want to share. You are
>> asking a very difficult thing to do in order to get Bind10 to run on
>> Windows at all. On top of everything you then have to make sure that the
>> memory references are refreshed whenever the "owner" of that memory
>> makes changes to it. It's a horror show waiting to happen.
> 
> Well, the idea was mostly to avoid threads, so emulating fork by threads isn't
> what I would like to want.
> 
>> Tell me again why you didn't make sure that the code was thread-safe
>> even if you are not using threads? It also will prevent you from using
>> I/O Completion Ports on Windows since that requires threads.
> 
> I'm not sure what completion ports are, but I guess it wouldn't be too portable,
> so we probably won't use that anyway.
> 

I/O Completion Ports is an optimization on Windows to manage I/O, which
has plenty of advantages but it doesn't have to be used. Happily also
sendmsg and recvmsg are now available though in Microsoft's usual
slightly different flavor (WSASendMsg() and WSARecvMsg()). It's all very
maddening.

> But it isn't thread safe for three reasons:
>  • Historical. It was started without them and adding them later is problematic.
>  • Difficulty. Using threads always brings bugs. It is hard not to forget
>    locking something or don't do a deadlock and the bugs tend to appear just
>    from time to time. So we agreed that if we can avoid them, then we would like
>    to.
>  • Performance. Even if it is small, the structures must be locked at each
>    access.

I remember a discussion with Paul several years ago. Every choice you
make has obstacles and overhead. Windows, oddly enough, has one of the
best implementations of threading and is reliable. The problem of course
is locking and there is overhead to pay for that. But you also pay for
creating separate processes and needing extra to for communicating
between them. And then there is a problem when the receiving end doesn't
get the message what should the code do?

> So, the idea with fork was that there's no need to make it thread safe. It it is
> too much of a problem not having multi-CPU support on windows, then we can't use
> that solution, of course.
> 

Windows can be single-threaded and it probably will work fine, and most
of the code will be much more generic as long as there aren't too many
Unixisms in the code. I've managed to find solutions to all of them that
I've had to deal with but it can be a very painful process.

>>>> Regarding frequency with which these operations are done, the
>>>> co.uk
>> zone is updated using dynamic updates every minute. So we would need to
>> think about restarting processes on a minute-by-minute basis.
> 
> Yes, and if you answer 50kQPS per thread, then it is one fork every 3 milions of
> queries. The fork on unix systems is light enough.
> 
>> There's no real equivalent to fork() on Windows. It won't be cheap on
>> Windows.
> 
> I don't want to support that fork on windows at all. The original idea was that
> windows would use only single CPU for authoritative. Yes, that is a limitation,
> and I'm not sure if it is worth it or not. But if we need to dance with threads
> to go around fork on windows, then it's better to just use threads for every OS.
>  

You can use a single CPU on Windows of course though I'm sure customers
will raise questions on it. I don't consider that an obstacle.

Danny