[Freeipa-devel] [PATCH 0077] Refactor settings subsystem
Petr Spacek
pspacek at redhat.com
Mon Oct 8 13:29:53 UTC 2012
Hello,
this patch refactors setting subsystem. After some experimenting I chosen
simple implementation with static arrays, no RBT trees involved. Speed can be
improved by reordering items in arrays.
Commit message:
Refactor settings subsystem.
Settings are stored in tree of settings_set_t structures.
All settings should be accessed only through setting* functions.
Mutual exclusion during write is done by switching to single
thread mode.
Setting_get() function doesn't copy strings, so changing the
original string can lead to obscure bugs.
This way is okay as long as strings are not changed dynamically
at run-time.
Unknown setting in configuration file leads to failure rather than
silent ignoring it.
https://fedorahosted.org/bind-dyndb-ldap/ticket/53
https://fedorahosted.org/bind-dyndb-ldap/ticket/81
Adam, I'm still looking for way how to handle strings in settings. We have to
prevent string change/deallocation as long as somebody has a pointer to the
string (I mean pointer obtained through setting_get("name_of_setting") call).
The only way which I can see is returning setting_string structure like
setting_string struct {
isc_refcount_t counter;
isc_mem_t *mctx;
char *str;
};
Caller has to call setting_string_free() when string can be freed.
Setting_string_free() will decrement counter by one and free whole structure
if and only if counter reaches 0.
Is it meaningful? Should I separate setting_get_* for each datatype? Or just
for setting_get_string() and let setting_get() universal for integers and
booleans?
--
Petr^2 Spacek
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bind-dyndb-ldap-pspacek-0077-Refactor-settings-subsystem.patch
Type: text/x-patch
Size: 86363 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20121008/2b247852/attachment.bin>
More information about the Freeipa-devel
mailing list