On Sept. 10, 2013, 12:07 p.m., Robin Hack wrote:
Just one issue, otherwise the patch looks good to me.
Ok. This is real issue. Copying can be avoided by using g_quark_from_static_string () instead.
What I want is try to avoid hash collision because this is what i found in glib source code:
* Note that the hash functions provided by GLib have these qualities, * but are not particularly robust against manufactured keys that * cause hash collisions. Therefore, you should consider choosing * a more secure hash function when using a GHashTable with keys * that originate in untrusted data (such as HTTP requests). * Using g_str_hash() in that situation might make your application * vulerable to <ulink url="https://lwn.net/Articles/474912/">Algorithmic Complexity Attacks</ulink>.
I use quark to get unique string identifier and use them as key in hash table where pointer to lock_t structure is stored.
Now i know, that i must/should use something which is quark but not quark from glib. Because glib use hash lookup anyway.
quark_from_string (const gchar *string, gboolean duplicate) ... quark = quark_new (duplicate ? quark_strdup (string) : (gchar *)string); ...
- Robin
----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviewboard-openlmi.rhcloud.com/r/842/#review1140 -----------------------------------------------------------
On Sept. 10, 2013, 7:29 a.m., Robin Hack wrote:
This is an automatically generated e-mail. To reply, visit: http://reviewboard-openlmi.rhcloud.com/r/842/
(Updated Sept. 10, 2013, 7:29 a.m.)
Review request for OpenLMI Developers.
Repository: openlmi-providers
Description
Account: Added associative thread locking.
Diffs
src/account/lock.c PRE-CREATION src/account/lock.h PRE-CREATION src/account/LMI_AccountProvider.c c7c16bb2beb1ef37e804e7cc7dce6bd182e6d55b src/account/CMakeLists.txt 495d7c6e3e1e083541d3ed004518dc4539f61d48
Diff: http://reviewboard-openlmi.rhcloud.com/r/842/diff/
Testing
Thanks,
Robin Hack