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

[Michal 'vorner' Vaner]

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.

> 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.

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.

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.

> >> 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.

Have a nice day

-- 
Have you ever been told you are an airplane?

Michal 'vorner' Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20110209/eb8f75cd/attachment.bin>