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.
The 'new' "unbound-control set_option" command seems to allow the
modification of many configuration variables by directly writing to the
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
operation. AFAICT, it is possible for these variables to be written and
read simultaneously on multiprocessor systems. The variable
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
understand to be _conservative_ best practices for cross platform code.
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.)
* 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. *
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.
Thanks much,
Jake Montgomery
_______________________________________________
Unbound-users mailing list
[email protected]
http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
