https://bz.apache.org/bugzilla/show_bug.cgi?id=65159
Yann Ylavic <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #38021|0 |1 is obsolete| | --- Comment #39 from Yann Ylavic <[email protected]> --- Created attachment 38022 --> https://bz.apache.org/bugzilla/attachment.cgi?id=38022&action=edit Atomic counter This is the patch finally proposed for backport. I don't really anticipate an overhead for the atomic operation, it should be in the noise (MPM event makes use of atomics for instance already to schedule the connections). It's in any case lighter than a system call to getrandom() or "/dev/urandom" for instance, though we might need to use that (directly or via apr_uuid_get()) or a (sip)hash at some point to add more randomness to the ID (as Joe or Eric said). This leaves the question of how much we can/want to grow the unique ID size, it's currently 27 characters (uuencoding of 20 bytes), 32 characters would be better IMHO as the uuencoding of following 24 bytes: - uint32_t timestamp in seconds (for compatibility) - char root[12] for the long term unicity of the child process - uint64_t siphash of a 32bit counter and 64bit/microseconds timestamp and... (the 128bit secret for siphash would be randomly generated at child_init) Or we could simply use: - uint32_t timestamp in seconds (for compatibility) - char data[16] from apr_uuid_get() or apr_generate_random_bytes() which is still 20 bytes, though possibly a bit longer to generate depending on the platform.. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
