[bind10-dev] Thoughts on Architecture of Xfrin & Notify-In/Out

Michael Graff mgraff at isc.org
Mon May 17 15:34:36 UTC 2010


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2010-05-16 10:28 PM, zhanglikun wrote:
>> Why are you choosing to use threads here, when we choose not to use
>> threads in something like the auth server, but instead choose to use
>> more than one process?
>>
>> That is, what does using threads gain over multiple processes?
> 
> I think the count of auth srv processes is fixed, no matter how many queries
> coming( Can the count of auth srv processes be setted in runtime), but xfrin
> processes is different. 
> If one transfer-in with one process, My concern is there will be too many
> xfrin processes at worst. Is there any other excuse?

I would consider writing it as one-transfer-per-process, but write the
underlying code such that it can be made threaded later.

That is, write it such that the "main()" function does something like:

  transfer = Transfer.init("flame.org", "1.2.3.4", ...)
  transfer.run

with the transfer.run part enclosed in an exception block to catch any
failures.

The idea is that this structure can later easily be changed to do more
than one transfer at a time just by putting threads in one place.
Luckily for us, the transfer in code is unlikely to have any interaction
between the threads.

- --Michael

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkvxYgwACgkQ+NNi0s9NRJ0TBQCeLFNFmpzlBlBW4E6asAJyJZ8N
oHEAn2c+IfLN5SxL268LVEb2taw2EB9p
=lciM
-----END PGP SIGNATURE-----



More information about the bind10-dev mailing list