-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Jake,
On 08/12/2011 11:01 PM, Jake Montgomery wrote: > I'm a developer, and I sometimes make custom modifications to the the > unbound code. I am a bit confused about the assumptions being made in > the unbound code with regard to what is safe on multiprocessor systems. It is multiprocessor safe. > The 'new' "unbound-control set_option" command seems to allow the > modification of many configuration variables by directly writing to the Yes, it comes from the set_option() call to libunbound which accepts the same parameters (and because it executes before libunbound starts it support almost all options very well). And it was very few lines of code to provide the function in the live server - proviso that it does not support all of the options. What would work is in a threaded unbound compile you change 'boolean' style options. Changing a single integer is fairly safe on multiprocessor machines, and using that as a boolean - remember that the other threads only read, so the worst that could happen is that they get a garbled value read back. For a boolean, 0 or not zero, this is very harmless. For other variables, yes indeed, but you are saved by modern cpus where the 'sig_atomic_t' is equal to 'int', therefore, you do not see 'garbled' versions of the integers. If something needs stronger support, this can be provided but would need special code. set_option is a power-user interface. get_option is much more useful and highly appreciated, I hear, in some environments (for accountability). > globally shared config_file structure. Most of these variables are never > used after initialization (which begs the question - why make them > settable?) However, some of them are accessed directly during normal Well they are settable because in libunbound, it works, and is a user interface to set the options you want the validator to use. > operation. AFAICT, it is possible for these variables to be written and > read simultaneously on multiprocessor systems. The variable Yes but only one thread can write, and the others read. And this is 'int', often similar to 'sig_atomic_t', and very often interpreted as booleans. Hence I am not worried about it. > config_file->log_queries is one of many examples. I have not done an > exhaustive search, but the examples I have found are all single integer > values. Nonetheless, concurrent writing and reading goes against what I Pfew :-) > understand to be _conservative_ best practices for cross platform code. Yes. Set_option for some options may need special support. Also, if you are not running threaded but forked, I believe the set_option command it sent and also processed by the other processes, and it would work fine there. > In addition, the variables are not marked as volatile, so it would be > theoretically possible for subsequent reads to be optimized out by the c > compiler, resulting in the settings changes not being reflected in > behavioral changes on worker threads, other than the one which processed > the command. (Admittedly, this is possible in theory, but unlikely in > the extreme in practice, given current compilers and the scope of the > variables.) Yes. > > * This is not intended as a troll or criticism, and I have the utmost > respect for the creators and maintainers of the unbound code base. * thanks, blush :-) > It would be helpful for me to understand what assumptions and guidelines > the unbound code uses for unprotected concurrent memory access. Armed > with this information, I could make my modifications in a manner > consistent with the current code. The set_option is indeed as we spoke about. In other code (the cache), there are proper mutexes. For handling control commands (i.e. not set_option) it uses pipes to signal and do IPC. Also there is signal handling with proper volatile sig_atomic_t declarations. The set_option command certainly seems to be too powerful, and not easy to understand, and with the concerns you rais, I wonder if it may be better to remove the command from unbound-control (it would stay in libunbound because that works). Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOSNj/AAoJEJ9vHC1+BF+N60QP/jJuR9qau2ENppHcnKFUHgRy zXveUpUoC0o2tSbI8Fc0YVGIimgHue4zqDbcvk/kFHoV+f23kxHsFyWfZi1E1ckX mUHHmH8Mx+gKH6s5sqpNiDjifRKbs7jG2lM6oXYZ+wfhiarNabt8OAXLHmwkT37i cSmlIRpKjCQfpVKJpByqJ6sx4V1KOUaoTW8K+v3ANLEctR+N6I5xyAoJI4tnsc9g Ra/We/EauMhvxpemnlk17lqhVF+DmarigDfIxwdtVbzLQq87SSV448hpRIW4q0CU iFtwfS2Qo29z6frOAYw6n4Bx7R/jKHjo05aBPJFeL9d8zjWaUi9zMGLElBBSIhUo 1sTtUuwDEsIL+kGc/QPkrSnzE4t5gW0DnuoidLFQLbDcKOvX6GTM/qfQuTm3ldeI dqLnYNu6KwNVvW0Gz2cF4Zm9iD7WBQqfs9kv6v1ClDWT1CYWzKjB1qlYLFGq6qOE OkKLQRKupt+OnHnqA7AKESQKjlm3QuAK0mdH3CRF6N1lIOOrvFUv1OxYiRVgNGgc EbhAzztTDU6gWBK3Rxq6YGecZUgpKLscePR+RmLXHFbIU8ajMYJ6cvcrOsA6K0TZ PuG2ReWLYAaEeXfxdSFZmtnGSY6MIB5DtZYoVeOmMufNrrDEmwTh746iqzdBnVIf 5Y9VT9vB2n9Pp+RZ81Is =n99e -----END PGP SIGNATURE----- _______________________________________________ Unbound-users mailing list [email protected] http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
